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experiments have been conducted to date, and a fourth is in 
planning. All have employed the Distributed Dynamic 
Decisionmaking III simulation, developed for this type of 
experiment, and all have involved variants of the same 
amphibious scenario. The purpose of this thesis is to help 
the A2C2 research team prepare for Tier II experiments. The 
target platform for Tier II is the Marine Air Ground Task 
Force (MAGTF) Tactical Warfare Simulator (MTWS) , a detailed 
and highly realistic stochastic simulation designed to train 
decision-makers. The author investigated the degree to 
which Tier I techniques and procedures can be transitioned 
to Tier II/ MTWS by adapting the A2C2 scenario to the MTWS 
environment. This thesis also discusses extracting 

experimental data from MTWS . 



1H00L 

01 



v 






VI 



TABLE OF CONTENTS 



L INTRODUCTION 1 

A. BACKGROUND I 

B. Current Status 2 

1. Experiments 1 and 2 3 

2. Experiment 3 3 

C. Transitioning to MTWS 5 

D. Terminology 7 

1. Forces 8 

2. Simulation vs. Scenario 8 

3. Players 8 

4. MTWS T erms 8 

5. MTWS Instructions. 9 

IL BUILDING THE MTWS SCENARIO 11 

A. Creating and Initializing the New Scenario 11 

1. Direct Changes 13 

2. Creating Batch Files 13 

B. Working with batch files 14 

1. Batch File Names. 14 

2. Recording a Batch File 17 

C. Parametric Database 29 

D. Other Settings 30 

1. Clock 30 

2. Mode/State 30 

HL PRE-START STATION CONFIGURATION 33 

A. Windows Layout 34 

B. Map Window Settings 34 

C. Controller Assignments 35 

D. Station Control Window 36 

IV. PLAYING THE SIMULATION 39 

A. Frequently Used Commands 39 

1. Air 40 

2. STS (Ship to Shore) 41 

3. Fire Support 41 

4. Ground 41 

5. Intelligence 42 

6. CE 42 

7. CSS. 42 

8. Environment 42 

9. NBC. 42 

B. Map Window Functions 42 

C. Spot Reports 43 

V. EXTRACTING DATA FROM MTWS 45 

A. Log Files 45 

1. Command History 45 

2. Spot Report Log 47 

vii 



B. Future Capability 49 

VL EVALUATION 51 

A. MTWS Issues 51 

1. Identification 51 

2. Combat 53 

B. DDDvsMTWS 54 

1. Tasks 54 

2. Capabilities 57 

VIL CONCLUSIONS 63 

A. Conclusions 63 

B. Reccommendations 64 

1. Red Forces and Neutral Targets 64 

2. Combat 64 

3. Unbiased Controller 65 

4. Dedicated Controllers. 65 

5. MARS Capability 66 

APPENDIX A . BATCH FILE LISTINGS 67 

APPENDIX B. UNIT LISTINGS 83 

APPENDIX C. ARCHITECTURES 85 

APPENDIX D. THE A2C2 SCENARIO 89 

APPENDIX E. CHANGES MADE TO THE PARAMETRIC DATABASE 97 

A. Landmines 97 

B. Bridges 97 

C. Default Terrain 98 

D. Ship Maximum Detection Range 98 

APPENDIX F. STARTING MTWS 99 

A. Before Loading MTWS 99 

1. MTWS System Control (MSC) 99 

2. MTWS Application Network (MAN) 99 

3. MTWS Display Station (MDS) 100 

B . Starting MT W S 100 

1. Start MSC 100 

2. Load MAN 100 

C. Loading or Creating an Exercise 101 

1. Creating an Exercise 101 

2. Loading an Exercise 101 

LIST OF REFERENCES 103 

INITIAL DISTRIBUTION LIST. 105 



viii 



LIST OF FIGURES 

Figure 1. Sample list of batch files to create units.... 16 

Figure 2. Sample batch files to be used by players 17 

Figure 3. Contents of a batch file 18 

Figure 4. Layout of terrain in the A2C2 scenario 19 

Figure 5. Log of a CE-CONSTRUCT command to create a road. 21 

Figure 6. Sample batch file created from a command to 

define an infantry unit 22 

Figure 7. Batch file that defines an aircraft carrier and 

airfield 24 

Figure 8. Defining an air mission 26 

Figure 9. Transferring a unit from ship to shore 27 

Figure 10. Defining a beach 27 

Figure 11. Instructions for automated unit movements.... 29 

Figure 12. Recommended MTWS Windows Layout 33 

Figure 13. Display Options Menu 35 

Figure 14. Command Menu Options 40 

Figure 15. Sample data from "command. history" file 46 

Figure 16. Command History data imported into Excel 48 

Figure 17. Sample data in spot report log 49 

Figure 18. Architecture AO pre trigger 85 

Figure 19. Architecture AO Post-Trigger 86 

Figure 20. Architecture A1 86 

Figure 21. Architecture A2 87 

Figure 22. Architecture AO prime. 87 

Figure 23. Architecture AO prime Post-Trigger 88 



IX 



EXECUTIVE SUMMARY 



The goals of the Office of Naval Research sponsored 
Adaptive Architectures for Command and Control (A2C2) 
research project are to study current and future joint 
command and control (C2) issues and develop theories about 
adaptive C2 architectures. Participants in the A2C2 project 
include representatives from ALPHATECH Inc., APTIMA Inc., 
University of Connecticut, George Mason University, 
Carnegie-Mellon University, Michigan State University, and 
the Naval Postgraduate School . 

The project includes three tiers of model-based human - 
in-the-loop experiments ranging from ones using simple, 
highly abstract computer-based simulations (Tier I) , through 
more complex, realistic simulations (Tier II) , to 
involvement in wargames and operational experiments (Tier 
III) . Three Tier I experiments have been conducted to date, 
and a fourth is in planning. The A2C2 project is designed 
around a model -experiment -model concept, which is an 
iterative process that bases the structure and hypotheses of 
future experiments around the results of previous 
experiments . 

Tier I studies have been conducted at the Naval 
Postgraduate School since March 1996, and have involved 
officer-students from several curricula. Tier I studies are 
conducted on a wargame-like simulation called Distributed 
Dynamic Decisionmaking (DDD) III that was modified 



xi 



specifically for the A2C2 project. In Tier I experiments, 
each player acts as the Decision-maker, staff, and computer 
operator . 

In addition to further Tier I testing, the next phase 
of the A2C2 project involves initiation of Tier II 
experiments. The target platform for Tier II experiments is 
the Marine Air Ground Task Force (MAGTF) Tactical Warfare 
Simulator (MTWS) , which is a detailed, realistic, stochastic 
simulation designed to train decision-makers. 

The basic scenario used in the Tier I experiments will 
be the foundation for the scenarios to be used in the 
initial Tier II experiments. Because of this, studies must 
be performed to examine the feasibility of implementing Tier 
I scenarios on MTWS. Additionally, while later Tier II 
experiments may have dedicated and trained MTWS operators 
(so the decision-makers do not have to bear the burden of 
learning and operating the simulation) , the initial 
experiments in MTWS will likely mirror the Tier I 
experiments in the sense that the subjects of the experiment 
will also be the computer operators for the simulation. 
This means that steps need to be taken to simplify certain 
procedures in MTWS, to accommodate players who may have 
little to no experience with MTWS. Finally, since the 
simulation will change, and the complexity of the experiment 
will increase during this transition, some of the methods 
used to extract data from the computer will be different. 
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Techniques for data extraction from MTWS will need to be 
established prior to Tier II experimentation. 

The purpose of this thesis will be to facilitate the 
transition of the A2C2 research from Tier I to Tier II by 
demonstrating how the scenario used in DDD III can be 
developed in MTWS. This thesis covers four major areas.' 
The first demonstrates how a working version of the A2C2 
scenario can be developed using modular approach based on 
text-based batch files, while the second area describes how 
the simulation would be played in an experiment. The next 
area discusses possible methods for data extraction from 
MTWS, and the final area discusses the tradeoffs that must 
occur in the transition from DDD to MTWS, including a 
comparison of specific issues pertaining to each simulation. 
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I. 



INTRODUCTION 



"The Adaptive Architectures for Command and Control 
(A2C2 ) research program is a multi-year, multidisciplinary 
effort to: (1) establish a body of knowledge in current and 
future joint command and control, and (2) develop and test 
theories of adaptive architectures. A guiding principle of 
the A2C2 program is that a practical knowledge of the 
interactions between the organizational and task (mission) 
structures is a precursor to the design of flexible 
organizations." [Ref 5], 



A2C2 


is an 


Office of 


Naval Research 


(ONR) funded 


project 


that involves research and representatives from 


ALPHATECH 


Inc . , 


APTIMA Inc. 


, University of 


Connecticut , 


George 


Mason 


University, 


Carnegie -Mel Ion 


University, 


Michigan 


State 


University, 


and the Naval 


Postgraduate 


School . 










A. BACKGROUND 









A2C2 plans envision three tiers of human- in- the- loop 
experiments that will fulfill the overall objectives of the 
A2C2 program. Tier I, the first phase of experimentation, 
involves controlled experiments, many with officer-students 
at the Naval Postgraduate School playing the roles of Joint 
Task Force (JTF) decision-makers. Tier I uses the 
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Distributed Dynamic Decisionmaking (DDD) III simulation, 
which was specifically modified for use in A2C2. Tier I 
experiments are highly abstract with each human player 
acting as a decision-maker, staff, and the computer 
operator. Tier II experiments are similar to Tier I, but 
will use a more realistic model for the simulation, and will 
expand on the experimental data and hypotheses generated in 
Tier I experiments. Finally, Tier III experiments will 
transition the A2C2 project from simple exercises involving 
of ficer- students to wargames and operational exercises that 
may involve an actual JTF commander and the forces and 
assets that would be used in a real-world military 
operation . 

An overall goal of the A2C2 project is to eventually 
transition its findings to actual military operations. This 
is partially done throughout the project using an iterative 
approach designed around a model -experiment -model concept 
that exists within and between each tier of experimentation. 
The results and data collected from each experiment 
conducted at the Tier I level will likely affect changes in 
following experiments. Additionally, findings from Tier II 
and Tier III experiments may prompt further Tier I testing. 

B . CURRENT STATUS 

To date, three experiments have been conducted at the 
Naval Postgraduate School, all at the Tier I level. The DDD 
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was used to simulate a Joint Task Force (JTF) conducting an 
amphibious assault. Each experiment was conducted using 
officer-students at NPS as. the decision-makers, and was 
planned and conducted by A2C2 researchers with assistance 
from students who had participated in prior experiments. 
The most recent was Experiment 3, conducted at NPS in 
November of 1997. 

1. Experiments 1 and 2 

Experiment 1 was conducted in March of 1996. The 
objective of Experiment 1 was to evaluate the basic 
experimental techniques for Tier I, and to gather an initial 
set of data. Experiment 1 explored the issues associated 
with resource conflicts between two and three level command 
hierarchies. [Ref. 1] . 

Experiment 2 was conducted in November of 1996, and 
built on the results of Experiment 1. In addition, it began 
looking at architectural adaptation, examining the effect of 
changes in mission, diversion of forces, and as the actions 
of enemy forces. [Ref. 1] . 

2 . Experiment 3 

Experiment 3 is discussed here in more detail because 
this experiment is also being used, in part, as the basis to 
begin the Tier II experiments. 

Fifty-four military officers (0-3 to 0-4) in the 
Joint Command, Control, Computers and Intelligence, and 
Management Sciences curricula were assigned to six-person 
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teams representative of a Joint Task Force command 
structure. [Ref. 5] . 

"Nine teams responded to an initial scenario that 
simulated an amphibious assault mission in a six-node 
architecture. A trigger event was then introduced that 
involved the loss of approximately 30 percent of the 
available assets. At the end of a planning session teams 
were asked to choose from one of three architectures: (1) 

their former, six-node architecture with reduced assets, (2) 
a five-node architecture, that was similar to their original 
architecture, with assets somewhat better distributed for 
the mission, or (3) an 'optimal' four-node architecture, 
quite different from their original architecture, with 
assets specifically distributed for the mission's tasks. 
Each team then engaged in two additional scenarios, one in 
the architecture they choose and one in another, in a 
counter-balanced design." [Ref. 5]. 

Experiment 3 evaluates the same issues as the previous 
experiments, as well as some new ones. The primary 
hypothesis investigated in Experiment 3 was that in a 
situation where teams are forced to adapt their structure, 
given a choice, they will choose the architecture that most 
closely resembles the one that they are most recently 
familiar with rather than the one that is most suitable for 
the situation (proximity vs. optimality) . [Ref. 1] . 
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Preliminary results of Experiment 3 supported the 
initial hypothesis, but also brought some other issues to 
light. The data collected confirmed that some level of 
"learning" was occurring in each successive trial. This 
means that the teams and individual players become more 
familiar with the scenario and simulation causing a slight 
performance increase in each trial, which is independent of 
the architecture used. [Ref. 1] . Normally, due to 

counterbalancing, learning is not a problem, but in this 
case, the possibility exists that it reflects, in part, 
inadequate mastery of certain skills required in some 
architectures, but not others. If so, it may have 

influenced players' choices. The results of Experiment 3, 
including the learning result, will be used to develop 
Experiment 4, which is scheduled for the summer of 1998. 

C. TRANSITIONING TO MTWS 

"The context in which we study architectural adaptation 
is Joint command and control, or more precisely the Joint 
Task Force (JTF) command staff. It is therefore essential to 
make sure that the architectural forms emerging from the 
basic research effort, and tested in experiments, have a 
certain degree of face validity. The conduct of officers-in- 
the-loop experiments at NPS, the progressive evolution from 
Tier I (DDD) to Tier II (MTWS) experimentation have 
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been designed to achieve this transition, while maintaining 
a rigorous scientific approach. " [Ref 6] . 

In addition to further Tier I testing, the next phase 
of the A2C2 experiment is the transition to Tier II. The 
most likely candidate for the Tier II experimentation is the 
MTWS simulation. This transition is likely to be a 
complicated process. The basic scenario used in DDD will be 
the basis for the scenarios that will be used in the initial 
Tier II experiments. Because of this, feasibility studies 
need to be performed that verify MTWS' suitability to the 
task. Additionally, while later Tier II experiments may 
have dedicated and highly trained MTWS operators (so the 
decision-makers do not have to bear the burden of learning 
and operating the simulation) , the initial experiments in 
MTWS will likely mirror the Tier I experiments in the sense 
that the subjects of the experiment will also be the 
computer operators for the simulation. This means that 
steps need to be taken to simplify certain procedures in 
MTWS to ensure that it can accommodate players who will most 
likely have little to no experience with MTWS. Finally, 
since the simulation will increase the realism and 
complexity of the experiment, and since MTWS data collection 
processes are different from DDD's, methods used to collect 
data will have to change. Techniques for data extraction 
from MTWS will need to be established prior to Tier II 
experimentation . 
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The purpose of this thesis will be to facilitate and 
explore this transition. A2C2 Experiment 3 is the model 
used for scenario development in MTWS. This is done in four 
major segments: MTWS scenario development, execution, data 
extraction, and evaluation. 

The remainder of this thesis, starting with Chapter II, 
explores the methodology used to build the A2C2 scenario in 
MTWS. This will primarily be done by using text based batch 
files that, when used in a modular approach, make the 
building and modification of the various architectures used 
in Experiment 3 a simpler process. The process of 
configuring MTWS workstations for use in the A2C2 scenario 
is discussed in Chapter III. Chapter IV evaluates the 
actual gameplay of the scenario in MTWS and the issues that 
needed to be confronted to overcome the complexity of the 
MTWS interface. An overview of possible data extraction 
schemes is provided in Chapter V. As part of the transition 
process, Chapter VI highlights some of the differences 
between MTWS and DDD in terms of issues that are important 
to the A2C2 experiment, and finally, Chapter VII provides 
recommendations and conclusions to continue this transition. 

D . TERMINOLOGY 

Certain terminology used in this document has specific 
meanings that should be clarified to avoid confusion. 
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1 . 



Forces 



The terms blue and red forces generally refer to 
friendly and enemy forces respectively. Blue forces, in the 
context of this document and the A2C2 experiment also refer 
to the forces that will be manipulated by the participants 
of the experiment . 

2. Simulation vs. Scenario 

Scenario is used to refer to the operational mission 
that is the focus of the A2C2 experiment. The operation 
plan of the A2C2 scenario is outlined in detail in Appendix 
D. Simulation refers to the specific implementation of the 
A2C2 scenario in MTWS . 

3 . Players 

Players, in this document refers to the individuals who 
are participating as subjects in the A2C2 experiment. 
Operators are the individuals who actually operate the 
terminals. The simulation was developed so the participants 
could act as both players and operators, even though this is 
not necessary. Chapter V discusses this in more detail. 

4 . MTWS Terms 

MTWS Station Control (MSC) refers to the computer that 
is acting as the primary server for the MTWS simulation. 
MTWS Display Stations (MDS) are the individual computers in 
the MTWS network that provide the actual interface for the 
game players . 



8 



5. 



MTWS Instructions 



During the course of this document, there are often 
references to specific windows and menu operations. A 
window is referenced by its title which appears in the 
center of the very top of the window. MTWS contains many 
menu options nested inside other menus. When referencing 
multiple menu operations, the notation MENU->SUBMENU1- 
>SUBMENU2->0PTI0N means that the option or function that is 
referenced is actually two menus deep. Certain files on the 
MTWS server are often listed in this document. When they 
are mentioned directly in the text, they will appear in 
quotes . 
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II. BUILDING THE MTWS SCENARIO 



This section will explain the initial steps required to 
launch MTWS, create and start a new scenario and use batch 
files. It is assumed that the reader has been exposed to 
MTWS or has MTWS reference materials available. Batch files 
allow MTWS commands to be issued from a file. Some are used 
in examples, but a complete listing of batch files used in 
this thesis and their contents is located in Appendix A. 
MTWS source materials, such as the MTWS Training Handbooks, 
[Ref. 4]. provide more detail on the specifics of MTWS 
commands and are available in the Systems Technology Lab 
(STL) . 

A. CREATING AND INITIALIZING THE NEW SCENARIO 

After initializing MTWS, as described in Appendix F, 
select the CREATE option using the computer configured as 
the MTWS System Controller (MSC) . This option is available 
in the MTWS Systems Operations window under the Exercise 
Control menu, in the DATABASE-> EXERCISE submenu. The 
window that pops up as a result of the CREATE command 
contains several critical options. The new scenario must be 
given a unique name (one that doesn't exist locally on the 
MTWS network) , a start time is specified if needed, and a 
user defined parametric database is selected. Since the 
A2C2 experiment has special requirements, a previously 
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modified version of the MTWS parametric database created 
specifically for the A2C2 experiment must be selected. 
Details of creating and modifying the parametric database 
appear at the end of this chapter. Select USER DEFINED from 
the list of options, and another window will open that lists 
the available customized databases. Select the appropriate 
database. For this experiment select the database called 
A2C2_DATA. The user defined parametric database must be 
defined and saved before the scenario is created. Anytime 
modifications are made to the parametric database the 
scenario must be created again. Each time a scenario is 
created, it makes its own copy of the parametric database. 
No topographic data is specified for the A2C2 scenario, 
because in this implementation of the scenario, a flat earth 
model is used. 

The scenario start date and time is user selectable, 
and should be considered carefully. Once the start time has 
been selected, the system clock can only be moved ahead, 
never backwards. It is important to know the system time 
because many of the batch files used in the scenario to 
automate the actions of the red forces are triggered at a 
specific time; they will not execute until' the specified 
time occurs in the scenario. The new exercise can now be 
loaded using the LOAD option. The parametric database will 
load, and the system clock will be set to the selected start 
time . 
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The next steps create both the artificial and natural 
terrain features and then the friendly and enemy units used 
in the scenario. The items created can be added to the 
scenario in one of two ways: direct changes to the scenario 
or batch files. 

1. Direct Changes 

The first method of building or modifying an exercise 
involves loading the scenario and then modifying the 
scenario by manually issuing commands through they keyboard. 
Once the desired units and assets are in place, issue the 
SAVE option under the same submenu as the LOAD command. 
Because of the requirements of the A2C2 experiment, this 
method is not the best method. A unique scenario would have 
to be created for each architecture used, a time consuming 
and error prone process . 

2 . Creating Batch Files 

MTWS has a powerful scripting utility that allows a 
user to easily create batch files that can contain commands 
within the file to set up a scenario or automate the 
simulation. Invoking the file name causes these commands to 
be executed. This is the recommended method for building 
scenarios for the A2C2 experiment . Since the A2C2 
experiment requires as many as six architectures, and all 
the architectures bear some similarities to the others, it 
makes sense to use a modular approach to building these 
scenarios. For each unit needed in an architecture, a 
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unique batch file is created that will automatically define 
this unit. If similar units are required for other players, 
or multiples of the same unit are needed for one player, the 
initial batch file can simply be copied and modified to 
reflect the characteristics of the new unit. 

B. WORKING WITH BATCH FILES 

This section describes how batch files are used to 
build an MTWS scenario. The use of batch files is 
especially useful for the A2C2 application because of the 
ease with which custom scenarios can be built around the 
core mission described in the experiment . Because of the 
large number of files required for this experiment, it is 
important to have a comprehensive batch file naming 
convention to avoid confusion. The following examples show 
how batch files are built and how each one is named. 

1. Batch File Names 

Figure 1 lists a sample set of batch files containing 
complete MTWS commands that, when invoked, create the 
infantry units required for the scenario. The remainder of 
this section describes the batch file naming convention used 
in A2C2 . The following section describes how to build batch 
files. The first batch file on the list is 
"a2c2_p4_inf l_p4_lhal . " The a2c2 prefix is included in all 
the batch files that were used to develop this scenario in 
order to distinguish them from the hundreds of other 
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miscellaneous files that reside in the same directory. If 
desired, the default directory for batch files can be 
changed by modifying a file called "/mtws/mds/ .prof ile" . 
Edit that file and change the parameter called CE_BATCH_PATH 
to the desired path. 

The second part of the file name is p4 . This space is 
reserved for the owner of the unit, in this case, p4 , or 
Player 4 . There are six possible players in the A2C2 
scenario, p0-p5. The third part of the filename is inf2 . 
This refers to p4 1 s second infantry unit. Note that in 
Figure 1, p2 also has an inf2 . During simulation play, unit 
names will include the player number as a prefix so they can 
be easily distinguished. Finally, the last 2 parts of the 
filename are p4_lhal . This simply indicates the initial 
position of the infantry unit, in this case on player 4's 
LHA. If a unit's initial position is not located on another 
asset, no location will be specified in the batch file name. 
For instance, if a unit were to be placed in the field, its 
batch file name would be "a2c2_p4_inf 2 . " 

Since the unit's initial position is located on another 
asset (LHA1) , it is important that the file defining player 
4's LHA is defined and invoked prior to the infantry unit's 
creation. The batch file "a2c2_p4_lhal " must be invoked 
before "a2c2_p4_inf 2_p4_lhal" . In some architectures. 
Player 4 requires another infantry unit to be placed on the 
same ship. The file "a2c2_p4_inf l_p4_lhal " is then copied 
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to a new file called M a2c2_p4_inf 2_p4_lhal . " The contents 
of the new file need to be modified as well. In this case 
all the instances of infl would need to be changed to inf2 . 
This illustrates how easily and accurately similar units can 
be created when compared with the tedious manual method. 



a2c2_j?4_inf 2_p4_lhal 
a2c2_p4_inf 2_p2_lpdl 
a2c2_p4_inf l_p4_lhal 
a2c2_p4_inf l_p2_lpdl 
a2c2_p3_inf 5_p2_lhal 
a2c2_p3_inf 4_p2_lhal 
a2c2_p3_inf 3_p2_lpdl 
• a2c2_jp3_inf 2_p2_lpdl 
a2c2_p3_inf l_p3_lpdl 
a2c2_p3_inf l_p2_lpdl 

a2c2 p2 infl p2 lhal 

Figure 1. Sample list of batch files to create units. 



The examples listed so far are for defining units. 
These types of batch files are only used once, at the time 
the simulation is loaded. Certain other batch files will be 
used by players while a trial is in progress . These batch 
files will usually used to automate tasks in MTWS that would 
be too complicated or time consuming for an A2C2 player to 
input manually. These include such tasks as launching an 
air mission, or transporting infantry units from ship to 
shore. The names of these types of batch file start with a 
word that indicates their function followed by additional 
information that describes the players that control the 
assets and the unit identification. Figure 2 shows a 
listing of batch files for creating and launching various 
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Close Air Support (CAS) units. The first line is the name 

of the file that would launch player one's first CAS unit, 

which is called P1_CAS1 . 

a2c2_launch_pl_casl 

a2c2_launch_p3_casl 

a2c2_launch_j?4_casl 

a2c2_launch_j?4_cas2 

a2c2_launch_p5_casl 

Figure 2. Sample batch files to be used by players. 

2 . Recording a Batch File 

Batch files are assigned to the MTWS Display Station 
(MDS) that creates them. The LOG menu item located at the 
top of the Command Entry window is used for recording and 
saving batch files. The OPEN command is selected under this 
menu, in order to start MTWS recording commands. MTWS will 
prompt the user for a unique filename. Since the technique 
used to develop the MTWS scenario requires such a large 
number of batch files, it is wise to adhere to the naming 
convention, such as the one outlined in the previous section 
and shown in and Figure 2 . Appendix A contains complete 
listings of all names and contents of batch files used in 
this particular A2C2 scenario. 

Once a log file has been opened, MTWS will append every 
successful command issued on the MDS that opened the log 
file into that batch file. If a command is rejected for any 
reason, it will not be stored in the batch file. 
Additionally, only commands issued in the Command Entry 
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Window for that MDS will be logged. Adjustments to the map 
settings or any other windows will not be recorded. 

Once the batch file is complete, the user can select 
the CLOSE option from under the LOG menu. When this process 
is completed, the resulting batch file is stored in the 
/mtws/db/cmd_entry/batch/ directory. Figure 3 shows an 
example of the contents of a batch file. The following 
sections will explain how various types of MTWS batch files 
are constructed and structured. 

CE; CONSTRUCT; RDl; ; ; IMPROVED_SURFACE; ROAD; AS PHLT-2-LANE ; (1352SEQ325127; 
52SEQ324121; 52SEQ317117 ; 52SEQ309120; 52SEQ305 117; 52SEQ303114 ; 52SEQ292 105 ; 

52SEQ2 69104 ; 52SEQ2 63 102 ; 52SEQ255087 ; 52SEQ222069; 5 2SEQ219066; 52SEQ210026 ; } $ 

C E ; C REAT E ; H I LL ; NATURAL_T E RRAI N ; MOUNTAI N ; HOUN TAI N ; {0652SEQ284126;52SEQ276122; 
52SEQ275 115 ; 52SEQ284 111; 52SEQ294116; 52SEQ292125 ; } $ 

CE; CREATE; PORT; STRUCTURE; PORT-FACILITY; 52SEQ315116; 15 ; 40; 100; $ 

Figure 3. Contents of a batch file. 

a) Creating Terrain 

Actual Digital Terrain Elevation Data (DTED) can 
be used in MTWS, but for the purposes of the A2C2 
experiment, it is not implemented since the geographical 
layout in the scenario is mostly fictitious. The elevation 
data would not necessarily be consistent with the terrain 
features created specifically for this A2C2 scenario and 
could cause confusion for the players. 

Figure 4 shows an approximate layout that was used 
for the A2C2 scenario. Once an appropriate geographical 
setting has been selected, the MTWS user can start creating 
terrain features. The interface for creating terrain is the 
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same interface used to manipulate units and create missions. 
All the commands and options to create man-made or natural 
terrain features are located under the CE-CREATE and CE- 
CONSTRUCT menu items under the command menu. The CE-CREATE 
function is generally used to create natural terrain 
features, such as rivers and hills, while the CE-CONSTRUCT 
option can also build other features such as roads or 
obstacles, such as minefields or antitank ditches. If an 
existing unit is specified in the CE-CONSTRUCT command then 
MTWS will simulate the actual construction process. 
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To create Road 1, as shown in Figure 4, the CE- 
CONSTRUCT command is selected. The resulting dialog box 
includes the object name, RD1 . Several optional parameters 
are listed for this command, and in this particular case, 
these parameters were left blank. The next option is the 
selection of the type of structure that is to be 
constructed. In this case, IMPROVED SURFACE was chosen, the 
type was selected as ROAD, and the sub- category was chosen 
as ASPHLT-2-LN. The final option was to select the sequence 
of points that the road is to follow. These coordinate 
values could be manually entered, but the most efficient way 
is to enter these values by clicking the cursor on the map 
window at the desired location. Once the points for the 
road have been selected, the user presses the transmit 
button, the command is processed, and the entry, shown in 
Figure 5, is made in the log file. 

In the batch file structure, a semicolon separates 
each option that was input by the user. In the case of 
optional fields that were left blank, a semicolon is still 
inserted in the batch file to act as a place holder for that 
particular option. The options that are shown in the file 
are exactly as they appeared in the dialog box. Thirteen 
points for RD1 are listed in this box using MTWS 1 coordinate 
system. Since multiple points could be selected for the 
road location, these points appear inside brackets. The 
very first point is prefixed by the number 13. This is to 
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tell MTWS that thirteen data points follow. When editing 
batch files manually, it is very important to make sure this 
prefix represents the actual number of data points. For 
example, the user may have decided to take out a certain 
bend in the road by removing two points. The 13 must be 
reduced to 11 to account for the points that have been 
removed. Many commands in MTWS treat multiple data points 
using this convention, including flight routes, unit asset 
updates, and ground troop movements and missions. Since a 
single batch file command usually takes up multiple lines of 
text, the end of the command is denoted by a "$". 

CE; CONSTRUCT ;RD1; ; ; IMP ROVE D_S U R FAC E ; ROAD ; AS PHLT - 2 - LAN E ; { 1352SEQ325 127 ; 
52SEQ324121; 52SEQ317117 ; 525EQ309120; 52SEQ305117; 52SEQ303114 ; 52SEQ292105 ; 

52SEQ2 69104 ; 52SEQ263102 ; 52SEQ255087 ; 52SEQ2220 69; 52SEQ219066; 52SEQ21002 6; } $ 

Figure 5. Log of a CE-CONSTRUCT command to create a road. 

Since the terrain features in this A2C2 experiment 
are unchanged between the different trials, are the terrain 
commands were created in one large batch file called 
"a2c2_create_terrain . " 

b) Creating Units 

A similar process is used to create ground, sea, 
and air units. From the Command Entry Window, the Ground- 
Unit-Define menu option is chosen. The user is prompted for 
information regarding the unit, including whether they want 
to use the Table of Organization and Table of Equipment 
(TO/TE) database that is included with MTWS. The TO/TE 
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database includes predefined unit asset listings for various 
friendly and enemy units at all levels of command. In the 
case of the blue forces in this experiment, the TO/TE is 
almost always used. The command to create an infantry unit 
that is used in this scenario would be logged in a batch 
file as shown in Figure 6. 

UNIT; DEFINE ; P4_INF2 ; LF; INFANTRY; PLATOON; P4_LHA1 ;MANC0N_5 ; ; SIMULATED; FALSE ; 

YES ; USMC ; I FY_3 ; $ 

Figure 6 . Sample batch file created from a command to 
define an infantry unit. 

This batch file is the contents of the first file 
listed in Figure 1. Like the example file that defined a 
road, each option is separated by a semicolon. If this file 
is used as the basis for other batch files that create 
infantry units, the parameters that must be changed are 
P4_INF2 (name) , P4_LHA1 (location) , and MANC0N_5 
(controller) . The location in this case is a ship, but map 
coordinates can also be used in this field. The eighth 

parameter in the batch file in Figure 6, is MANC0N_5 . This 
parameter is the controller assigned to the unit. In this 
experiment, each player is assigned a specific controller. 
MANC0N_1 through MANC0N_6 are the controllers for players 0 
through 5. The controller (s) assigned to a specific player 
will determine which unit-specific information is directed 
to each player. If a player controls P2_INF1, this infantry 
unit will need to be assigned to MANC0N_3 . Any computer 
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generated reports regarding P2_INF1 will be directed to all 
stations that have been assigned MANC0N_3 as a controller. 
This will be discussed in greater detail in Chapter III. 

c) Predefining Air Missions 

Individual aircraft are not considered units in 
MTWS . Rather, they are assets that may be allocated to a 
particular air squadron. To ensure that an air mission can 
be executed during an MTWS scenario, several things must 
occur first. An air squadron as well as fuel and support 
squadrons need to be defined and positioned where the 
airfield is to be located. These are all defined using the 
GROUND- >UNIT->DEFINE under the COMMAND menu option in the 
Command Entry window. For the sake of simplicity in this 
experiment, the same squadron is used for the air support 
and air fuel squadrons. Ordinance loads also need to be 
defined using the AIR- >ORDINANCE LOAD->DEFINE menu item. 
The ordinance loads in MTWS only define a template for the 
types and amount of ordinance needed for an air mission, and 
not the actual load itself. Only one ordinance load needs 
to be defined for each type of armed air mission to be 
flown. The fuel/supply unit will need enough fuel and 
weaponry to support all the air missions that will be flown 
from that location during the trial . Fuel and assets are 
added using the GROUND- >UNIT->UPDATE command. An airfield 
can now be defined using the COMMAND- >AIRFIELD- >DEFINE menu 
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option and filling in the appropriate information. In the 
A2C2 experiment, all of the friendly airstrips are located 
on ships. The airfield must have the same name as the ship 
in order for MTWS to function properly. 

Figure 7 shows the batch file that defines an 
aircraft carrier as well the collocated airfield. In this 
sample, there are no aircraft defined. Aircraft are 
allocated using separate batch files. Since the number and 
type varies with each mission, a batch file has been created 
for each pair of aircraft to be used. 



UNIT; DEFINE; P1_C VI ; LF; SHIP; COMPANY; 52 SEQ35 4 037 ;MANCON_2 ; ; SIMULATED; FALSE; 
YES ; USN ; JFK_CLAS S ; $ 

UNIT; DEFINE ; P1_CV1_AIRSUPPLY; LF; SUPPLY; COMPANY; P1_CV1;AIRC0N; ; SIMULATED ; 
FALSE ; YE S ; USMC ; MAT_S UP ; $ 

UNIT; DEFINE ; P1_CV1_AIRSQUAD; LF ; AI R_S QUADRON ; SQUADRON; P1_CV1 ; AIRCON; ; 

S IMULATED ; FALSE ; YES ; USMC ; VMAAW; $ 

AIRFIELD; DEFINE ;P1_CV1;P1_CV1 ; OPEN; P1_CV1_AI RSUPPLY;P1_CV1_AIRSUPPLY; 

{ 0 1 P 1_CV1_AI RSQUAD ; } { 0 0 ; } $ 

ASSETS ;UPDATE;P1_CV1_AIRSQUAD; ASSET; {04MK-84-BOMB;500;OPERATIONAL; 
ZUNI-RKT-4; 500; OPERATIONAL; 20MM-HE-AC; 1000 00; OPERATIONAL; MAVERICK- TV-MSL; 
500; OPERATIONAL; } $ 



Figure 7. Batch file that defines an aircraft carrier and 

airfield. 



In the A2C2 experiment, all combat aircraft are 
operated in units of two. The batch file " a2c2_pl_casl" 
defines and allocates two FI 8s to the air squadron on the 
aircraft carrier. While several batch files exist to define 
CAS aircraft for different players, there is actually no 
difference in contents of these files. Separate batch files 
for CAS with distinct file names were created only to 
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facilitate use by the person who is required to build a 
specific architecture using these batch files. 

Once all the requisite units have been defined, 
the air missions can be defined. Batch files to launch each 
aircraft unit were created to ease this process for the 
players. If Player 4's CAS unit needs to be launched, the 
batch file called a2c2_launch_p4_casl is executed. This 
file will execute the instruction shown in Figure 8. Note 
that this air mission is defined with the same name as the 
unit it represents (P1_CAS1) . 

Since close air support (CAS) was used in the 
mission type in Figure 8, a supported unit was required by 
MTWS for this mission. The unit P5_ENG was used, but any 
friendly ground unit could have been used here. Setting 
this option does not preclude the air mission from 
supporting another ground unit. The last portion of this 
command, enclosed in brackets, defines the actual route of 
the air mission. In this case, the purpose is only to 
launch the aircraft, so a way-point close to the launch site 
was chosen, and the aircraft was put into a medium orbit. 
The aircraft will continue to orbit until the player 
controlling it issues an AIR->MISSION->DIVERT command. 
Chapter III will discuss, in more detail, how air missions 
are controlled by the players. 
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AI R_MI S S I ON ; DEFINE ; P 1_CAS 1 ; FA- 1 8 ; 2 ; P 1_CV1_AI RSQUAD ; P 1_CV1 ; ; ; 

P5_ENG; CAS ; CAS_ORD; ; ; FALSE ;TAKE_OFF; ; { 0152SEQ334058 /MEDIUM; ORBIT; }$ 

Figure 8. Defining an air mission. 

d) Ship to Shore 

Most of the ground units used in the A2C2 scenario 
are initially positioned onboard ships. MTWS requires a 
series of commands to be executed in order to airlift a unit 
from a ship to a specified location on the ground. This 
series requires three commands. AIR MISSION->DEFINE, STS- 
>SERIAL- >DEFINE , and STS->SERIAL->ASSOCIATE under the 

COMMAND menu option in the Command Entry window. A serial 
is a ship to shore operation that involves transport of 
cargo, assets, or troops. A serial, in this example, is 
defined in terms of a predefined air mission and an existing 
ship. This sequence and the example shown in Figure 9, 
assumes that the prerequisites for an air mission, similar 
to the one described in the previous section and in Figure 
7, have already been met. It also assumes that beaches with 
landing zones have been defined. In MTWS, a beach is not a 
terrain item. Instead it is a logical construct used for 
planning purposes and for defining missions. Because of 

this, the option to define a beach is located under the STS 
(ship-to-shore) menu item. 

Along with the beaches, checkpoints also need to 
be defined. Figure 10 shows the batch file to define the 
beaches and checkpoints. The user is prompted for beach 
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start points and end points, as well as a line of departure, 
a causeway, and start and stop points for the underway 

launch line. Since most of these parameters do not factor 
heavily into this exercise, but are required for MTWS to 

accept the BEACH- >DEFINE command and to display it on the 
map. Chapter IV provides an overview on MTWS usage, 

including how to turn off various display items, including 
the beach geometries. 

When a checkpoint is defined, it must also be 
specified as a landing zone. To define a serial, a landing 
zone parameter is required, and the command will not be 

accepted until a landing zone has been specified. In this 
scenario, the checkpoints for the two beaches were SB and NB 
(South and North Beaches) , and these are referenced in the 
SERIAL- >DEFINE command shown in Figure 9. 

AIR_MISSION; DEFINE ; LHA_LAND_P2_INFl_SB;MV-22 ; 1; 

P2_LHA1_AI RS QUAD ; P2_LHA1 ; ; ; ; STS;TAKE_OFF; ; {OlSB;MEDIUM;UNIT_DROP; } $ 

SERIAL; DEFINE; LHA_LAND_P2_INF1_SB;LF;P2_LHA1;USE_0F_AIRCRAFT; {01P2_INF1; }SB; 
MV-22;1;$ 

SERIAL; ASSOCIATE; LHA_LAND_P2_INF1_SB;LHA_LAND_P2_INF1_SB; $ 

Figure 9. Transferring a unit from ship to shore. 



BEACH; DEFINE ; SOUTH_BCH;LF; 52SEQ230006; 52SEQ245020; ; ; 52SEQ232004 ; 52SEQ24 901 6; 
52SEQ237015; {0352SEQ252014;52SEQ236002;52SEQ252004; } ; ;;$ 

BEACH; DEFINE;NORTH_BCH; LF; 52SEQ268065 ; 52SEQ289074 ; ; ; 52SEQ269061 ; 52SEQ292071 ; 
52SEQ279073; { 0352SEQ275060 ; 52SEQ2 93066; 52SEQ289054 ; } ;;;$ 

CHECKPOINT; DEFINE; NB; 52SEQ276071; LF; YES ;$ 

CHECKPOINT ; DEFINE ; SB ; 5 2 SEQ2 35 0 1 2 ; LF ; YE S ; $ 

Figure 10. Defining a beach. 



27 



e) Creating Red Forces 

In this exercise, enemy forces are created in a 
similar manner to blue forces, but are fully automated. In 
many cases, the automation is a default MTWS behavior. Any 
unit (including a blue unit) will automatically try to 
defend itself if threatened or attacked by an opposing 
force. Ground units can also be defined and put in a 
defensive posture (which increases their defensive 
capability) or they can be moved automatically at specific 
times . 

One portion of the exercise requires blue forces 
to identify trucks moving along two different roads. The 
trucks are timed to appear in 2-3 minute intervals. This is 
done by issuing a GROUND- >UNIT- >MISSION command. Most 
mission commands give the user an option to specify a start 
time. These commands are issued with a specific start time 
and are logged into a batch file. The batch file with these 
time lagged commands is invoked at the beginning of the 
scenario, but not executed until the specified time. The 
sample file in Figure 11 shows the commands that instruct 
the trucks to start moving at certain times. These times 
need to be specified relative to the simulated start time of 
the scenario. If the start time of the exercise is changed, 
all automated batch files need to be updated as well. MTWS 
uses the 24 hour time format, referenced to Greenwich Mean 
Time (GMT) also known as Zulu time. For example, 
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241914ZFEB98 would 1914 hours (7:14 pm) on 24 February, 1998 
in the Greenwich London (Zulu) time zone. 

UNIT /MISSION; TRK2 /MOVE ; COLUMN; ;MV_PLANS ; NO; ; ;241914ZFEB98; (06RD3; /S2SEQ221078; 

; RDS; ; 52SEQ218066; ;RD1; ; 52SEQ2 10025 ; ; }$ 

UNI T ; MI S S I ON ; TRK4 ; MOVE ; COLUMN ; / MV_PLANS ; NO ; ; ; 2 4 1 9 1 7 Z FEB9 8 ; { 0 6RD3 ; ; 5 2 S EQ2 2 1 0 7 8 ; 

; RD5 ; ; 52SEQ218066; ;RD1; ; 52SEQ2 10025 ; ; }$ 

UNIT /MISS ION; TRK5 /MOVE /COLUMN; ;MV_PLANS ; NO; ; ;241920ZFEB98; {06RD3; / 52SEQ221078 ; 

; RD5 ; ; 52SEQ218066; ;RD1/ ; 52SEQ2 10025 ; ; }$ 

UNI T ; MI S S ION ;TRK6; MOVE; COLUMN; ;MV_PLANS ; NO; ; /241924ZFEB98; {06RD3; ; 52SEQ221078 ; 

; RD5 ; ; 52SEQ218066; ;RD1; ; 52SEQ210025 ; / }$ 

UNIT ; MIS S ION ; TRK8 ; MOVE ; COLUMN ; ; MV_PLANS ; NO / ; ; 2 4 192 7 Z FEB98 ; { 0 6RD3 ; ; 5 2 SEQ2 21078; 

/ RDS; ; 52SEQ218066; / RD1 / ; 52SEQ2 10025 / / )$ 

Figure 11. Instructions for automated unit movements. 

During the A2C2 scenario, various enemy units, 
usually artillery, will appear and disappear on the display 
to simulate enemy movements. This is done to increase 

pressure on the players and influence their command and 
control (C2) decision making cycle. This task is easily 
accomplished by assigning these units missions which move 
them closer to where blue forces might be located for a few 
minutes and then moving them away again. Similar procedures 
can be used to automate enemy and neutral sea and air units . 
In the scenario, Red forces also deploy both land and sea 
mines. These minefields are created using the CE- >CONSTRUCT 
menu command. Appendix A provides batch file listings for 
all the red forces implemented so far. 

C . PARAMETRIC DATABASE 

The Parametric Database is the portion of MTWS that 
stores all information regarding unit, vehicle, and weapon 
characteristics. This database is highly modifiable, and 
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many traits of current systems and units can be varied to 
represent new or different capabilities. This is useful for 
the A2C2 experiment. Although the experiment is designed to 
simulate a real world amphibious assault, the A2C2 scenario 
would require too much time and be too complex for the 
experiment itself. Additionally, blue forces in the 
experiment have been purposely designed to be stronger than 
the corresponding red forces. Early loss of key units in 
this simulation would effectively change the architecture 
being tested, and therefore would skew the data. Minefields 
and bridges have also been modified in the parametric 
database. Once they have been detected, they can be removed 
in a time efficient manner. 

D . OTHER SETTINGS 

1 . Clock 

The simulation has been configured to operate optimally 
at a time compression factor of 1:1. This is the default 
setting in MTWS, but the option can be changed in the MTWS 
Station Control window under the EXERCISE CONTROL- >RATE menu 
option to play at a faster rate, if desired. 

2. Mode/State 

When the simulation is loaded, the default state is in 
the ADMIN mode. To start the system clock running, this 
mode should be changed to RUN, through the EXERCISE CONTROL- 
OPERATION- >STATE menu option in the MTWS Station Control 
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window. Additionally, the EXERCISE CONTROL- >OPERAT ION- >MODE 
menu option should be set to RESUME if it is currently in 
SUSPEND mode. 
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III. PRE-START STATION CONFIGURATION 



Each MDS station in MTWS needs to be configured for the 
appropriate user. Before the MDS stations can be 
configured, the scenario must be loaded as described in 
Chapter II. Due to constraints in MTWS, station settings 
have to be reconfigured each time a new exercise is loaded. 



Command Entry 



Icon 



Icon 



Icon 



Icon 



,lr.nn, ,lr.nn, 



Map Window 



Spot Reports 



Status Window 



Figure 12 . Recommended MTWS Windows Layout 
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A. WINDOWS LAYOUT 

There are four windows that are essential to playing 
the scenario in MTWS . The command entry window, the map 
window, the spot report window, and the status window. 
Prior to the start of the scenario, these windows need to be 
sized and positioned so that they are always available to 
the player. Each window contains vital information or 
functionality that must be easily available to the player at 
all times. Figure 12 shows the recommended windows layout 
for an MDS station. 

B. MAP WINDOW SETTINGS 

The Display Categories menu item is used to turn 
certain items and units in MTWS on and off. This menu only 
contains two options: Display Objects, and Display 
Environment. This field should not be manipulated by the 
players. The Display Objects option brings up a window that 
allows users to vary the types of objects displayed on the 
map. The only option in this window that needs to be 
changed from the default settings is under the water 
category on the button labeled Objects. The user should 
select the Objects button under this option. Another window 
will open that lists several features. To make the display 
less cluttered, the Beach Geometries feature should be 
turned off. 



34 



Under the Display Environment menu option, a window is 
displayed that allows the user to control which players or 
forces are displayed on the map window. There are options 
available for controlled objects (units, ships, aircraft, 
etc.) and uncontrolled objects (minefields and other 
obstacles.) In both cases, the red forces (AG) and civilian 
forces (CIV) should be deselected, so they are not displayed 
on the map. These objects will only appear on the map 
windows if they are detected by blue forces. No other 
options in this window should be modified. 



Map Options 



Display Options 



Display Categories 



Locate 
Identify 
Calculator 
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Restore Map Colori 



Figure 13. Display Options Menu. 



C. CONTROLLER ASSIGNMENTS 

Controller assignments are made through the System 
Operations window which appears as an icon when an MDS 
station is first launched. Double clicking this icon will 
display the window. In the A2C2 scenario, each station used 
in the experiment should only have one controller selected. 
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To select a controller, the EXERCISE CONTROL menu option is 
selected, and the ASSIGN/DEASSIGN option is chosen. A 
window will open with all the possible controllers. If a 
certain station is to be used for Player 0, then MANCON_l 
should be the selected controller. If the station is for 
Player 1, the MANCON_2 should be selected, and so on. These 
controller assignment determine who controls units and which 
messages will appear in the Spot Report windows. It is 
important that a player is assigned only the necessary 
controllers so they are not overwhelmed by message traffic 
that doesn't pertain the their units. 

The computer that is configured as the MSC should have 
all the controllers assigned to it. This will allow the MSC 
to capture all the spot reports that are generated during 
the scenario and log them in a file. This is useful for 
data extraction as discussed in Chapter IV. 

D. STATION CONTROL WINDOW 

On each MDS station, there is an icon at the bottom of 
the display called MTWS Station Control. When this icon is 
double clicked, it opens up the Station Control window. In 
order for an MDS station to be included in a scenario, the 
status should be changed from Off Line to On Line. This 
will register the MDS station on the MTWS network. The 
privileges a user has over MTWS is determined by the User 
Privilege Level setting. The lowest setting, zero, only 
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allows the user to use the functions that are necessary for 
gameplay. When the privilege level is zero, users can not 
instantaneously move objects or units, and they cannot 
change the map display settings, or change controller 
assignment. Level two is the highest privilege setting and 
requires a password to be accessed. When an MDS station is 
being configured, and controllers are being assigned, the 
privilege level must be set to two. Before the scenario is 
started however, the level must be returned to zero. Level 
one is an intermediate level that allows an MTWS controller 



to have 


access 


to 


certain advanced 


functions, 


but 


not 


complete 


control 


of 


the scenario. 


Level one 


is 


not 



necessary for the A2C2 scenario. 
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IV. PLAYING THE SIMULATION 



This chapter is divided into two primary sections. The 
first section describes actions and commands that will be 
performed by the players. The second section describes the 
settings and parameters that need to be modified prior to 
the start of the scenario by the personnel responsible for 
administering the experiment . 

MTWS is a complex simulation that was originally 
intended for well -trained and knowledgeable users. Since 
participants of the A2C2 experiment typically have only 
limited experience using MTWS, it is useful to provide an 
outline of the key features and commands they will need to 
know in order to play the simulation. This chapter provides 
an overview of commands and instructions the players need to 
know . 



A. FREQUENTLY USED COMMANDS 

The MTWS commands used most frequently by the players 
for this simulation are instructions for ground unit 
operations and air operations. In the Command Entry window 
there is a menu option called COMMANDS. This menu item, 
when selected with the mouse, appears as shown in Figure 14. 
Since there are dozens of submenus, the items important to 
the A2C2 simulation will be highlighted in the following 
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sections . The only commands shown here are the ones that 
are important to the actual players during gameplay and do 
not include commands that are used for the creation of the 
scenario . 



CCjMMAND 



REPORTS 



AIR 


> 


FIRE SUPPORT 


> 


GROUND 


> 


INTELLIGENCE 


> 


CE 


> 


CSS 


> 


ENVIRONMENT 


> 


NBC 


> 


SHIP OPS 


> 



Figure 14. Command Menu Options. 

1 . Air 

AIR->MISSION->DIVERT allows the player to update an air 
mission that is already launched. This command requires the 
user to input an existing, and airborne, air mission name, 
as well as one or more locations. Each point is accompanied 
by settings for mission type (attack, waypoint, land, orbit 
etc.) and altitude (very low, low, medium, high). The user 
should specify the flight profile, and for this experiment, 
they must specify the last point as an orbit. This prevents 
the air mission from performing a Return to Base (RTB) 
automatically. If an air mission RTBs, it will be more than 
ten minutes of actual time before the simulation allows the 
aircraft to be launched again. Players should not use this 
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command to create and launch their own air missions. 



Instead they should use the batch files that perform this 
function . 

2. STS (Ship to Shore) 

This command is not needed by the players. All ship to 
shore operations are performed through batch files. 

3 . Fire Support 

FIRE SUPPORT- >DEFINE QUICK MISSION is used to provide 
naval gunfire. The quick fire support mission is the most 
useful for this scenario. It requires only target location 
information, or the target's name, the name of the firing 
ship, and the ammunition to be used. The players should 
have a list of available ammunition from each ship prior to 
the start of the exercise. 

4 . Ground 

GROUND- >UNIT->MISSION specifies actual unit and troop 
movements on the ground. The more important subcommands 
included in this command include the functions to MOVE, 
ATTACK, and DEFEND. There are options in this menu to 
control speed and to override to the default speed and 
movement settings for certain terrain. Both speed and 
movement override should be selected, and a desired speed 
manually entered. The players should enter a reasonable 
speed of 30 to 40 kilometers per hour (kph) . Like an air 
mission, a unit mission can involve multiple movements and 
functions . 
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5. Intelligence 

This command is not used by the players. 

6. CE 

CE- > REMOVE is the only command under this menu that the 
players will use. Only a player controlling an engineering 
unit can use this function. In this scenario, CE->REMOVE 
will be used to remove minefields and bridges. 

7. CSS 

This command is not used by the players . 

8 . Environment 

This command is not used by the players . 

9. NBC 

This command is not used by the players. 

B. MAP WINDOW FUNCTIONS 

The map window provides the primary interface from MTWS 
to the user. The menu item labeled Map Options is used to 
manipulate the position and zoom level of the map. The map 
display in MTWS is capable of displaying any level of detail 
from the world view down to a detailed level. A player can 
customize map settings so that the map encompasses only the 
units they are concerned with. The primary functions under 
this menu, to be used by the player, are the pan, zoom, and 
previous map options. The Map Manager feature located under 
this menu item allows the user to select a map background 
from a list of various digitized navigational maps, but this 
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feature is not used for this scenario. Any of these options 
will be available to players, but the most useful ones will 
be Identify, and Clear Locations. Identify allows the user 
to select an area of the screen containing red or blue 
units, and it will return information about these units, if 
the information is available. Information includes precise 
location, unit name, and unit type. This is most useful if 
players want to launch precision attacks through airborne or 
naval fire missions. The Clear Locations option cleans 
markers off the screen. Markers are created anytime a 
player clicks the mouse on the map area. After a period of 
time, these marks can significantly clutter the map display. 

C . SPOT REPORTS 

The Spot Reports window contains textual message 
traffic that pertains to the units assigned to the active 
controllers. Section B describes how to assign the active 
controllers to players and units. Information in the spot 
report windows is very useful because it is generally 
updated faster than the map window. Spot reports include 
pertinent information about a unit, such as enemy target 
sightings, status of a unit's mission, when a unit attacks 
or is attacked, as well as damage assessment to that unit. 
A player will only see spot reports pertaining to units 
under their control. 
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V. 



EXTRACTING DATA FROM MTWS 



This chapter will describe how MTWS collects data and 
highlight some of the possible methods for extracting 
exercise data from MTWS. There will be no discussion of 
methods used to analyze these data. 

A. LOG FILES 

When a scenario is loaded and running, MTWS maintains 
logs of for all commands that were successfully executed, 
and a log of all reports that are generated in the Spot 
Reports window are saved into a file. The files are 
automatically over-written each time MTWS is restarted. 
After completing each trial, these files need to be saved to 
a new location to prevent loss of data. These files are 
simple text files that can be used to evaluate which tasks 
were performed when, and how successfully they were 
executed. [Ref. 3] . 

•1. Command History 

The "command. history" file is located in the directory 
/mtws/db/man/ [exercise name]. In the case of this 
experiment-, it would be in the /mtws/db/man/A2C2 directory. 
This file contains a complete list of all the commands that 
were executed from the Command Entry window for that 
particular station. This file includes all the commands 
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that were executed when the batch files were invoked at the 
start of the scenario. The data in the "command . history" 
files are similar to the data that would appear in a batch 
file. Additionally, these data include the MDS station 
number of the player that executed the command, and the hour 
and minute (scenario time) that the command was executed. 
Figure 15 contains a few sample lines from a 
"command . history" file. 



241913ZFEB98 ;mds005 ; UNIT /MISSION; P5_S0F;M0VE ; VEE; ;MV_PLANS; YES; 30 ; OVERRIDE; ; {0 
352SEQ209088 ; ; 52SEQ214083; ; 52SEQ206076; ; } $ 

241913ZFEB98 ;mds005 ; UNIT; MI SSI ON; P5_ENG; MOVE; VEE; ;MV_PLANS; YES; 30; OVERRIDE; ; {0 
352SEQ206076; ; 52SEQ2 05076; ; 52SEQ205076; ; } $ 

2 4191 4 ZFEB98;mds005;UNIT; MISSION; P3_ENG;MOVE;VEE; ;MV_PLANS; YES; 30; OVERRIDE; ; {0 
152SEQ228100; ; }$ 

241915ZFEB98 ;mds005 ; AIR_MI SSI ON; DIVERT; P1_CAS1; {0252SEQ283120;MEDIUM;WAY_POINT 
; 52SEQ245 05 6;MEDIUM; ORBIT; } ;$ 

241916ZFEB98 ;mds005 ; UNIT; MI SSI ON; P3_INF2 ; MOVE; VEE; ;MV_PLANS; YES ; 30;NO_OVERRIDE 
; ; { 0152SEQ229025 ; ; } $ 

241916ZFEB98 ;mds005 ;UNIT;MISSION; P3_INF3 ;M0VE;VEE; ; MV_PLANS ; YES ; 3 0 ; NO_OVERRI DE 
;; { 0152SEQ229025 ; ; }$ 

241916ZFEB98 ;mds005 ; UNIT; MISS ION; P3_INFl ; MOVE; VEE; ;MV_PLANS; YES; 30;NO_OVERRIDE 
; ; { 0152SEQ229025 ; ; } $ 

2 4 1 91 8 Z FEB98 ; mds 005 ; UNIT ; MISSION; P3_INF1 ; MOVE ; VEE ; ; MV_PLANS ; YES ; 3 0 ; NOJOVERRI DE 
;; { 0152SEQ223019; ; } $ 

241919ZFEB98 ; mds 005 ; UNIT; MISS ION; P3_INF1; ATTACK; VEE; ;MV_PLANS;YES;30;OVERRIDE; 

; {0152SEQ222020; ; }$ 

2 41 919ZFEB98;mds005; UNIT ;MISSION;P3_INF2; ATTACK; VEE; ;MV_PLANS; YES; 30; OVERRIDE; 
; {0152SEQ222020; ; } $ 

241919ZFEB98 ;mds005;UNIT;MISSION;P3_INF3; ATTACK; VEE; ;MV_PLANS; YES; 30; OVERRIDE; 
; { 0152SEQ222020; ; }$ 

241920ZFEB98 ; mds 005 ; AIR_MI SS ION; DIVERT ;Pl_CASl; {0252SEQ223019;VERY_LOW; ATTACK; 
5 2SEQ2 3 8 030; MEDIUM; ORBIT; }TROOPS; $ 

Figure 15. Sample data from "command . history" file. 



One possible method of extracting data from this file 
would be to import the text file into a spreadsheet program 
such as Microsoft Excel. Excel allows a user to parse data 
into separate cells so it can be managed more easily, or 
sorted according to the analyst ' s preference . By studying 
this reorganized file, it is easy to determine if 
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coordinated attacks were executed properly. Similarly, the 
lines of text could be treated as database records and 
imported into a database program such as Microsoft Access 
for further data reduction and analysis. 

The "command. history" file collects commands from all 
MDS stations that are on the network into one composite 
file. This file can be extracted from any MDS. 

2 . Spot Report Log 

The other file that is useful to the data analysis is 

the spot report log. It is also specific to the MDS. This 

file is located in the /tmp directory and is called 

"Spot_Report_Log" . This file is a useful complement to the 
command history file. It contains every spot report that 
was generated on all the MDS stations. Like the command 
history file, this data also includes the time each spot 
report occurred, and which units were involved. Certain 
spot reports are useful because they quantify the casualties 
and damage inflicted on units during the simulated combat. 
The spot reports can be correlated to the commands in the 

"command. history" file, and the overall effectiveness of a 
particular task can be assessed in this manner. Figure 17 
shows sample output from a spot report log file. The spot 
reports shown here correspond to the commands shown in 
Figure 15 and Figure 16. 
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Figure 16. Command History data imported into Excel. 



In addition to the data that is collected by the 
computer, audio and video recordings are routinely made of 
each A2C2 trial. Additionally, A2C2 analysts also monitor 
the progress of the trial in real time. 

The "Spot_Report_Log" is station specific. As 
mentioned in Chapter III, all the controllers on the MSC 
should be activated. This allows the "Spot_Report_Log" file 
on the MSC to contain all the spot reports that were 
generated for the entire scenario. This prevents the time 
consuming process of consolidating separate files. 
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ENGAGEMENT STATUS CHANGE ; P3_INF2 ; 52SEQ224 022 ; 24192 0ZFEB98 ;MANC0N_4 ; HAS 
INITIATED ENGAGEMENT WITH SB_DEFENSE 
PRINTED BY: mdsOOS 

ENGAGEMENT STATUS CHANGE ; P3_INF3 ; 52SEQ224 022 ; 241920ZFEB98 ;MANCON_4 ;HAS 
INITIATED ENGAGEMENT WITH SB_DEFENSE 
PRINTED BY: mdsOOS 

STATUS CHANGE ;SB_DEFENSE; 52SEQ223020 ; 241920ZFEB98 ; AGC0N_1 ; RECEIVING 
AIR- TO- SURFACE FIRE 
PRINTED BY: mds 005- 

UNIT SB_DEFENSE ; P1_CAS1 ; TROOPS 1 WIA, 

PRINTED BY: mds005 

ASSESSMENT REPORT ; P5_ENG 

AI R_TO_S URFACE ; 52 SEQ2 06076/241920 ZFEB98 ; MANCON_6 ; 

UNIT SB_DEFENSE ; P1_CAS1 ; TROOPS 1 WIA, 

PRINTED BY: mds005 

ENGAGEMENT STATUS CHANGE; SB_DEFENSE ; 52SEQ223020 ; 241921ZFEB98 ; AGCON_l ; IS 
ENGAGED BY P3_INF1 
PRINTED BY: mds 00 5 

ENGAGEMENT STATUS CHANGE ; SB_DEFENSE ; 52SEQ223020 ; 241921ZFEB98 ; AGCON_l ; IS 
ENGAGED BY P3_INF2 
PRINTED BY: mds005 

ENGAGEMENT STATUS CHANGE ; SB_DEFENSE ; 52SEQ223020 ; 241921ZFEB98 ; AGCON_l ; IS 
ENGAGED BY P3_INF3 
PRINTED BY: mds005 

UNIT CASUALTY LIMIT ; SB_DEFENSE; 52SEQ223020 ; 241921ZFEB98 ; AGCON_l /HAS 
REACHED EFFECTIVE CASUALTY LIMIT 
PRINTED BY: mdsOOS 

REPORT ; GROUND_ENGAGEMENT 1/52SEQ224021/241921ZFEB98; AGCON_l , MANCON_4 ; 

UNIT SB_DEFENSE ; TROOPS 4 WIA, 3 KIA 
PRINTED BY: mdsOOS 



Figure 17. Sample data in spot report log. 

B . FUTURE CAPABILITY 

The MTWS Analysis and Review System (MARS) is an 
augmentation to MTWS that is currently under development. 



49 



The goal of the MARS system is to provide real time analysis 
of an exercise as well as an after-action review capability. 
MARS will require two additional MDS stations to run. [Ref. 
2 ] . 
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VI . EVALUATION 



The goal of this chapter is to provide an evaluation of 
the MTWS scenario in two ways. The first half of the 
chapter will discuss limitations and concerns that are 
unique to MTWS. The second half will compare current 
capabilities of the MTWS version of the scenario to those 
of the DDD version. 

A. MTWS ISSUES 

In many ways, MTWS is much less rigidly structured than 
DDD. MTWS does not force the order of events by requiring 
prerequisite tasks to be accomplished before players are 
allowed to continue. In addition, MTWS is stochastic in 
nature, so even though the specific probabilities of events 
occurring can be assigned in the parametric database, the 
outcome of any given event is a random variable. Several 
additional key issues have been identified that are 
significantly different between MTWS and DDD. 

1. Identification 

In DDD, air and sea tracks appear on the display as a 
question mark until they have been identified. A track can 
be identified by moving a friendly unit into detection 
range, and using the IDENTIFY option. MTWS does not allow 
such a clear cut process for identification. Most units 
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have sensors or communications with other units that can 



accomplish this, but unlike the configuration of DDD III 
used in the A2C2 scenario, the initial detection range units 
in MTWS does not cover the entire area of operations 
displayed on the computer screen. Because of this, an 

unknown track will not appear on the display until it has 
been detected. Once detected, it appears as a purple 



rectangle 


on the display. 


Even 


though a unit 


may 


be 


detected. 


only some or all 


of 


the information 


may 


be 


available. 


including size, 


type. 


and alliance 


of 


the 



detected unit. The spot reports displayed in the spot 
report window will often contain more information than is 
available on the map display. This process makes target 

detection and identification a much more complex process in 
MTWS. 

r 

The location of the enemy, in many cases, is known 
prior to the start of the scenario, so there is no 
difficulty in identification. The original DDD scenario 

uses of several "random" tracks that "pop up" and move 
around the screen. Identifying these tracks in DDD is a 
relatively simple process for the operator. The random 
track aspect of the MTWS scenario has not yet been 
implemented. If the same number of random tracks were used 
in MTWS, the task of detecting and identifying them would be 
more difficult and time consuming than DDD. When this 
feature is implemented in MTWS it should probably use a more 



52 



modest number of tracks than DDD in order to keep the 
scenario playable. Another alternative would be to modify 
the parametric database to increase the detection ranges of 
various units or to configure MTWS to simulate a UAV to 
increase the probability of detection of enemy targets. 

2 . Combat 

In DDD, if some or all of the criteria were met to 
conduct an assault on the enemy, the enemy unit would 
automatically be destroyed. However, if the attackers did 
not have adequate resources or properly time the attack, 
they would receive a lower score for the task. If the 
attacking units did not have any of the necessary resources, 
the computer would not allow the attack. In DDD friendly 
units can not be defeated, but the players are penalized in 
scoring their efficiency instead. 

In MTWS, unit composition and assets can be varied 
greatly. Blue forces can be configured to be substantially 
stronger or weaker than Red forces, but MTWS will not 
prevent any attacks the way DDD will. The effectiveness of 
the attack will be limited by the types of units used and 
the assets these units contain. Because combat in MTWS is a 
weighted, but stochastic process, the outcome of any 
conflict can not be absolutely pre-determined. 
Approximations were made in determining relative unit 
strengths for the MTWS scenario, but, with time and 
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research, a more reliable and predictable balance of 
strengths between Red and Blue forces could be determined. 



B. DDD VS MTWS 



There are several issues specific to the A2C2 scenario 
important to evaluating the performance of architectures. 
These issues, or factors that directly affect them have been 
compiled and listed in tabular format in this section. The 
issues have been divided into two sections. 

The first section is a listing of the specific tasks 
within the scenario that have to be completed by the 
participants of the A2C2 experiment. This section compares 
and contrasts any significant differences between MTWS and 
DDD that might affect or impact the gameplay of the 
scenario . 

The second section is capabilities, and these more 
general aspects of the A2C2 scenario or tasks that are could 
be completed at any time such as clearing sea mines. Issues 
that are more complicated or significantly different from 
the DDD implementation of the A2C2 experiment are discussed 
in this section. 

1 . Tasks 



Task: Releasing Assets 

Requirements: A player's assets are not necessarily 
initially under that player's control. An asset may be 
located on another asset, such as a ship which is controlled 
by a second player. The owner of the asset needs to request 
that second player release, or launch their asset. 



DDD 



MTWS 
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The DDD software requires a 
player to request that the 
second player release their 
asset. This request is 
mandatory in the software, 
and is usually followed by a 
verbal request as well. The 
second player must release 
the asset using a menu option 
in the DDD software. The 
second player is not able to 
release the asset unless the 
first player initiated the 
request through the DDD 
software . 



MTWS does not force this 
process as does DDD. The 
launching or releasing assets 
could by done by anyone, but 
the procedure forced by DDD 
should be followed, except 
that all requests and 
acknowledgements are only 
verbal . Since these 
functions are performed by 
batch files in MTWS, the 
process could be enforced by 
only making batch file names 
available to the player who 
is allowed to release the 
assets . 



Task: Landing Amphibious Forces 


Requirements: Players are required to release forces from 
various sea assets and transport them to the North or South 
Beaches using MV22s (airborne) and AAAVs (seaborne) . 


DDD 


MTWS 


A first player will release a 
second players MV22 or AAAV 
using the technique mentioned 
"Releasing Assets" section 
above. Once these units have 
landed at one of the desired 
locations, the second player 
will use a menu option to 
unload the units. 


Setting up either an airlift 
mission or a sea transport is 
more complicated in MTWS. 
Batch files were used to 
automate the process of 
airlifting units to the North 
and South beaches. Since 
batch files would have been 
used for sealift as well, the 
processes of sealift and 
airlift would have been 
indistinguishable to the 
players. In the current 
implementation of the A2C2 
scenario, airlift (MV22s) are 
used for deploying all units 
to the beaches . 



Task: Taking the Beaches 


Requirements: Several players are required to launch a 

coordinated attack on both the North and South beaches at 
the same time. 


DDD 


MTWS 


Each player selects the 
ATTACK option, and selects 
the desired target, and a 


Similar to DDD, each player 
can issue the commands to 
launch an attack, but not 
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confirmation dialog box will 
appear. Once all the players 
involved in the coordinated 
attack have accomplished 
this, they will all launch 
their attacks simultaneously. 
If the coordinated attack did 
not employ all required 
platforms, or did not time 
their attack properly, points 
will be deducted. 



confirm the attack until 
everyone is ready. Assuming 
the Blue forces appropriately 
out-mass the Red forces, the 
Red forces will be destroyed. 
If red forces are not 
destroyed, follow on attacks 
may be required. If more 
attacks are required (if too 
few or inappropriate assets 
have been used) then Blue 
forces will suffer more 
casualties. This information 
will be logged in the log 
files generated during the 
trial . It is up to the 
analysts to determine a 
method measuring the success 
of the attack. While the 
Blue forces have been 
configured to be 
significantly stronger than 
the Red Forces, the 
capabilities of both sides 
will need to be more 
accurately configured than 
they are in the current 
implementation. See Chapter 
VII for a more detailed 
summary of this issue. 



Task: Removing the Bridge 


Requirements: Blue forces are required to determine which 

one of two bridges needs to be destroyed by determining 
which one the enemy is using. This determination is made by 
identifying an enemy truck heading for the appropriate 
bridge . 


DDD 


MTWS 


In DDD, a reconnaissance 
aircraft or a satellite is 
required to identify if a 
truck is hostile or neutral. 
Once this determination has 
been made, a coordinated 
attack is required to destroy 
the bridge. 


In MTWS, aircraft can not 
identify a ground target and 
display it as a track on the 
map. Satellites capability 
is not implemented in MTWS. 
Ground forces in the area can 
employ sensor nets or 
visually identify the trucks. 
The enemy truck will appear 
as a company sized unit 
instead of a team size. The. 
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amount of time required to 
remove a bridge in MTWS is 
directly proportional to the 
Manpower applied, given that 
engineering units are used. 

If all the required units (as 
outlined in the operational 
plan) are used, the bridge 
will be removed in a matter 
of minutes. If not, it will 
take significantly longer to 
remove the bridge . 



Task: Taking the Hill 


Requirements: Coordinated attacks are required to capture 

and hold the hill. 


DDD 


MTWS 


This process is similar to 
the procedure used to capture 
the beaches, except the 
coordinated attack is limited 
to one enemy unit instead of 
two. Once the hill has been 
captured, a unit must hold it 
by issuing the HOLD command. 


The issues here are similar 
to the issues described for 
capturing the beaches. MTWS 
also has the capability to 
put units into a hold posture 
after they have defeated red 
forces . 



Task: Taking the Seaport 



Requirements: Coordinated attacks are required to capture 

the sea port . 



DDD 


MTWS 


This process is similar to 
the beaches or the hill. 


This process is similar to 
the beaches or the hill . 



Task: Taking the Airport 


Requirements: Coordinated attacks are required to capture 


the airport. 




DDD 


MTWS 


This process is similar to 


This process is similar to 


the beaches or the hill. 


the beaches or the hill. 



2. Capabilities 



Capability: Track Identification 

Requirements: Players are often required to identify 

ground, sea, and air tracks to determine whether they are 
hostile or neutral. 
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MTWS 



DDD 



This mission is performed by- 
moving within sensor range to 
the target in question and 
issuing an IDENTIFY command. 
The results of this are then 
automatically share with all 
the players. 



MTWS will automatically 
detect a track by displaying 
a purple rectangle on the 
screen. The spot report log 
has to be monitored to 
identify the type of unit, 
and whether it is hostile or 
not. The visual information 
is shared with all the 
players, but the spot reports 
are only displayed for the 
detecting units. 



Capability: Coordinated Attacks 


Requirements: The simulation requires that certain attacks 

require coordination between Blue forces. If the forces do 
not have all the capabilities required to accomplish the 
mission, they will either receive a lower score for the 
task, or they will not succeed. 


DDD 


MTWS 


This procedure is enforced 
through the software in DDD. 
Two or more players will 
launch an attack as described 
in the "Taking the Beaches" 
section. If less than the 
required forces are applied 
to the task, DDD will either 
give a low score or will not 
allow the task at all. 


MTWS will not prevent any 
unit from attacking another, 
even with inadequate 
resources. Attack missions 
will be far more efficient if 
the appropriate units are 
applied. MTWS does not score 
the results, but the log 
files can be analyzed to 
learn the damage inflicted on 
the enemy unit, and whether 
the players used the right 
forces for the job. 



Capability: Medivac Missions 


Requirements: Sometimes units sustain casualties after an 

attack, and a medivac mission is required before the unit is 
capable to continue operating. 


DDD 


MTWS 


Launching a medivac mission 
is as simple as releasing a 
medivac asset. Once this 
unit is operational, the 
ATTACK option is used on the 
wounded unit. The unit is 
then restored. 


MTWS can support medivac 
missions, but this capability 
is difficult to employ. 
Additionally, MTWS requires 
situation specific 
information (such as number 
of wounded and killed) so 
batch files could not be 
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used. This feature is not 
currently implemented. 



Capability: Clearing Sea Mines 


Requirements: Sea mines will likely block access to one or 

both of the beaches, and need to be cleared before the 
operation can continue. 


DDD 


MTWS 


DDD will automatically stop a 
ship from moving into sea 
mines once they have been 
detected. DDD will display a 
mine icon to represent the 
mines on the screen. A 
minesweeper needs to be moved 
into the area, and instructed 
to remove the mines . 


MTWS will allow ships to 
detect sea mines if the 
parametric database is 
properly configured. 

Otherwise the only way to 
find them is to run into 
them. The firepower of the 
mines can be reduced in the 
parametric database so the 
damage to naval assets is not 
significant. Ships will not 
stop when they encounter a 
minefield. The settings in 
MTWS require an enemy 
minefield to be displayed all 
the time or none of the time. 
Minefields will not be 
displayed on the screen after 
detection. No easy method 
was determined to remove sea 
mines. The sea mines 
capability to disarm them was 
researched, but not 
implemented . 



Capability: Clearing Land Mines 


Requirements: Blue forces will encounter land mines at 
"random" locations on some of the roads. Once these mines 
have been detected, and engineering unit is required to 
remove them . 


DDD 


MTWS 


DDD does not allow players to 
move around the mines, or 
through them until they have 
been removed. An engineering 
unit simply needs to approach 
the minefield, and issue the 
command to remove the mines . 


MTWS will stop land units 
when they encounter a 
minefield. Unless there are 
obstructions, (which can 
easily be put in place) , 
units can move off the road 
and around the mine field. 

An engineering unit is 
required to remove the 
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minefield. The amount of 
time and manpower required to 
remove a minefield was 
manipulated in the parametric 
database, so a minefield 
could be removed in a 
reasonable amount of game 
time . 



Capability: Clearing Tanks 


Requirements: Blue forces "randomly" encounter tanks which 

must be defeated before the mission can proceed. 


DDD 


MTWS 


A coordinated attack is 
required to remove a tank. 


MTWS functions similarly to 
the other coordinated tasks. 
The tanks can be configured 
so they are easily defeated. 
This was researched, but due 
to time restraints, not 
included in the implemented 
version. 



Capability: Clearing SAM Sites 


Requirements: SAM sites must be detected, and determined to 

be non-decoy or hostile before they can be destroyed. 

Certain other tasks can not be performed until a nearby SAM 
site has been destroyed. 


DDD 


MTWS 


DDD will not allow the 
following on task (such as 
taking the port) to be 
accomplished until the SAM 
site has been destroyed. 
Coordinated attacks are 
required to remove the SAM 
site . 


MTWS can not enforce the 
order of events, so while a 
SAM site may be present, 
units can still continue 
other parts of the mission at 
increased risk to air assets . 
MTWS includes SAMs in its 
database, but this feature 
has not been implemented yet 
due to time constraints. 



Capability: Removing Pop Up Targets 


Requirements: Various enemy air units appear on the screen 

from time to time. The units can be removed with a single 
air unit, or with naval gunfire support 


DDD 


MTWS 


When the target appears, a 
single aircraft or ship can 
attack if it is in range. 


This feature has not been 
implemented yet, but could 
easily be added by including 
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timed batch files to move 
enemy artillery units in and 
out of range of the Blue 
forces . These units can be 
configured to be relatively 
weak, so they can be 
destroyed by a ship or a 
single CAS mission. 



Capability: Clearing Hostile Tracks 


Requirements: Random and hostile air, sea, and ground 

tracks will appear periodically. These units should be 
identified and then destroyed. 


DDD 


MTWS 


Ships, ground units, and 
aircraft have the capability 
to detect some or all of 
these tracks. Neutral tracks 
may be destroyed, but it 
lessens a teams overall 
score. Most of these tracks 
can be removed with a single 
unit . 


Time based batch files can be 
used to automate the random 
tracks . Units in MTWS can 
detect a track if it is in 
sensor range . These 
automated units, like other 
Red force units will be 
configured so they are 
relatively easy to defeat 
with the appropriate units. 
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VII. CONCLUSIONS 



A. CONCLUSIONS 

This thesis set out to facilitate and explore the 
transition of the A2C2 project from Tier I experimentation 
to Tier II experimentation using the MTWS simulation. 

Using the method of developing multiple batch files for 
building the scenario and simplifying the simulation, and 
the modular approach to building scenarios, MTWS can easily 
accommodate modifications for subsequent experiments with a 
minimum of effort. The MTWS simulation will provide an 
operation that is driven much more by the course of scenario 
events than it is by aspects of the computer interface . 
This will provide an accurate assessment of command and 
control architectures which could be mapped into real-world 
organizational structures. 

MTWS is a viable platform for the continuation of the 
A2C2 project. Because of its detailed database that can 
realistically structure every aspect of the game, and its 
stochastic nature, it can provide much more of the real- 
world uncertainty that is often referred to as the "fog of 
war." Yet MTWS can still provide a highly controlled 
environment that can be used to perform repeatable 
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experiments that can assess the effectiveness of various 
command and control architectures. 

B . RECCOMMENDATIONS 

Although the author has concluded that MTWS can support 
the A2C2 project, several issues need to be resolved or 
investigated before the MTWS implementation of the A2C2 
scenario is ready for use in the transition from Tier I to 
Tier II experimentation. 

1 . Red Forces and Neutral Targets 

Virtually all the Blue forces have been implemented in 
the MTWS, except where noted in Chapter VI. Many of the Red 
Forces still need to be implemented. These include the 
hostile and neutral air and sea traffic as well as the pop 
up artillery units that appear from time to time in the 
scenario. Additionally, the shortcomings with enemy sea 
mine removal should be resolved. 

2 . Combat 

Red and Blue forces have been defined and equipped in 
MTWS so the outcome of combat will usually be favorable for 
Blue forces if the appropriate units are applied. The 
outcome will be closer to a draw if inadequate forces are 
applied. In the case where inadequate forces are used 
repeatedly, the attrition rates will most likely eventually 
eliminate Red Forces. 
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The probability of victory given the assigned units has 
not been assessed. Closed loop trials could be run on Red 
Forces versus Blue Forces to determine the outcome of a 
large number of engagements. This will help determine a 
realistic structure for Red and Blue forces so that Blue 
forces will be forced to fight, with desired attrition 
rates. It will also help the A2C2 analysts remove the 
effects of the probabilistic events in MTWS from the 
performance of the players. 

3. Unbiased Controller 

MTWS has a certain set of commands and capabilities, 
that allow an unbiased controller to have complete control 
over the simulation if necessary. This controller could 
perform functions such as allowing minefields to be visible 
after they have been detected, or overriding MTWS in cases 
where Blue units have been damaged beyond usefulness or 
killed. The controller could step in any situation where 
the software or computer equipment have a more significant 
impact on the outcome of a task or a mission than they 
should . 

4. Dedicated Controllers 

The MTWS concept was designed to that the people who 
were being trained or tested by it did not need to have any 
knowledge of the MTWS interface itself. Instead, dedicated 
computer operators would control MTWS workstation and act as 
an interface between the decision makers and the simulation. 
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While this method might eliminate the need for MTWS training 
for A2C2 participants, the addition of dedicated human 
controllers could present another variable that could impact 
the results of the experiment. Batch files that are used to 
automate tasks, as outlined in Chapter IV, could be used to 
further simplify the usage MTWS and further reduce the 
complexity for the operators. 

5. MARS Capability 

The MARS upgrade to MTWS will provide a wide array of 
analysis tools to the MTWS package. Many of these will 
automate the task a extracting and analyzing data during a 
trial as well as after a trial. [Ref. 2] . 
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APPENDIX A. BATCH FILE LISTINGS 



This appendix provides a complete listing of batch files and 
their contents in the current implementation of the A2C2 
experiment . 



a2c2_trucks_create 

UNIT ; DEFINE ; TRK1 ; CIV; CIVILIAN; TEAM ; 3 9DXE1103 0 9 ; C0NT_1 ; ; SIMUL 
ATED ; FALSE ; NO ; $ 

UNIT; DEFINE; TRK2 ; CIV; CIVILIAN; TEAM; 3 9DXE1103 09 ; C0NT_1 ; ; SIMUL 
ATED; FALSE ; NO ;$ 

UNIT ; DEFINE ; TRK3 ; CIV; CIVILIAN ; TEAM ; 3 9DXE110 3 0 9 ; C0NT_1 ; ; SIMUL 
ATED ; FALSE; NO ;$ 

UNIT ; DEFINE ; TRK4 ; CIV; CIVILIAN ; TEAM ; 3 9DXE11 0 3 0 9; CONT_l ; ; SIMUL 
ATED ; FALSE; NO ;$ 

UNIT; DEFINE ;TRK5 ; CIV; CIVILIAN; TEAM; 39DXE110309 ; CONT_l; ; SIMUL 
ATED ; FALSE ; NO ; $ 

UNIT; DEFINE; TRK6 ; CIV; CIVILIAN; TEAM; 3 9DXE1103 09 ; CONT_l ; ; SIMUL 
ATED ; FALSE ; NO ; $ 

UNIT ; DEFINE ; TRK7 ; CIV; CIVILIAN ; TEAM ; 3 9DXE1103 0 9 ; CONT_l ; ; SIMUL 
ATED; FALSE; NO; $ 

UNIT; DEFINE ; TRK8 ; CIV; CIVILIAN; TEAM; 3 9DXE1103 0 9 ; CONT_l ; ; SIMUL 
ATED ; FALSE; NO ;$ 

UNIT; DEFINE; TRK9 ; CIV; CIVILIAN; TEAM ; 3 9DXE1103 09 ; CONT_l ; ; SIMUL 
ATED ; FALSE; NO ;$ 

UNIT ; DEFINE ; TRK1 0 ; Cl V ; MOTOR_TRANSPORT ; SECTION ; 4 8DVG2 0 9 0 5 4 ; AG 
CON_l ; ; SIMULATED ; 

FALSE; NO; $ 

ASSETS ; UPDATE ; TRK1 ; TROOPS ; { 0 12 ; HEALTHY ; 

ASSETS ; UPDATE ; TRK2 ; TROOPS ; j 0 1 2 ; HEALTHY ; 



ASSETS ; UPDATE ; TRK3 ; TROOPS ; 
ASSETS ; UPDATE ; TRK4 ; TROOPS ; 
ASSETS ; UPDATE ; TRK5 ; TROOPS ; 
ASSETS ; UPDATE ; TRK6 ; TROOPS ; 
ASSETS ; UPDATE ; TRK7 ; TROOPS ; 
ASSETS ; UPDATE ; TRK8 ; TROOPS ; 
ASSETS ; UPDATE ; TRK9 ; TROOPS ; 



012; HEALTHY ; 
012; HEALTHY ; 
012; HEALTHY ; 
012; HEALTHY ; 
012; HEALTHY ; 
0 12; HEALTH^ Y; 
0 12; HEALTHY; 



ASSETS ; UPDATE ;.TRK10 ; TROOPS ; { 012 ; HEALTHY ; } $ 

ASSETS ; UPDATE ; TRK1 ; ASSET ; { 012 . 5 -TRUCK; 1 ; OPERATIONAL ; 
ASSETS ; UPDATE ; TRK2 ; ASSET ; l 012 . 5 -TRUCK ; 1 ; OPERATIONAL ; 
ASSETS ; UPDATE ; TRK3 ; ASSET ; j 012 . 5 -TRUCK ; 1 ; OPERATIONAL ; 
ASSETS ; UPDATE ; TRK4 ; ASSET ; | 0 12 . 5 -TRUCK; 1 ; OPERATIONAL ; 
ASSETS ; UPDATE ; TRK5 ; ASSET; { 012 . 5 -TRUCK; 1 ; OPERATIONAL ; 



$ 

$ 

$ 

$ 

$ 
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ASSETS ; UPDATE ; TRK6 ; ASSET ; { 0 12 . 5 -TRUCK ; 1 ; OPERATIONAL ; } $ 
ASSETS; UPDATE ;TRK7; ASSET; { 012 . 5 -TRUCK; 1 ; OPERATIONAL ; }$ 
ASSETS; UPDATE ;TRK8; ASSET; { 012 . 5 -TRUCK; 1 ; OPERATIONAL; }$ 

ASSETS ; UPDATE ; TRK9 ; ASSET ; { 0 1 2 . 5 - TRUCK ; 1 ; OPERATIONAL ; } $ 
ASSETS; UPDATE ;TRK10; ASSET; { 0 12 . 5 -TRUCK ; 1 ; OPERATIONAL ; }$ 
ASSETS ; UPDATE ; TRK1 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK2 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK3 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK4 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK5 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK6 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK7 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK8 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK9 ; FUEL ; 5 0 0 ; $ 

ASSETS ; UPDATE ; TRK1 0 ; FUEL ; 5 0 0 ; $ 

a2c2_run_trucks 

UNIT; LOCATE ; TRK1 ; 5 2 SEQ 1 2 8 1 1 9 ; $ 

UNIT ; LOCATE ; TRK3 ;52SEQ128119;$ 

UNIT ; LOCATE ; TRK7 ; 52 SEQ 12 8 119 ; $ 

UNIT ; LOCATE ; TRK10 ; 5 2 SEQ1 1 312 7;$ 

UNIT;MISSION;TRKl;MOVE; COLUMN; ; MV_PLANS ; NO ; ; ; 241913ZFEB98 ; {0 
5RD4 ; ; 52SEQ203076 ; ; 

RD5 ; ; RD1 ; ; 52SEQ210025 ; ; }$ 

UNIT ; MISS ION ; TRK3 ; MOVE; COLUMN; ; MV_PLANS ; NO ; ; ; 241917ZFEB98 ; {0 
5RD4 ; ; 52SEQ203076 ; ; 

RD5 ; ; RD1 ; ; 52SEQ210025 ; ; }$ 

UNIT ; MISS ION ;TRK7; MOVE; COLUMN; ; MV_PLANS ; NO ; ; ; 24 1917ZFEB98 ; {0 
5RD4 ; ; 52SEQ203076 ; ; 

RD5 ; ; RD1 ; ; 52SEQ210025 ; ; }$ 

UNIT; MISSION; TRK10 ; MOVE ; COLUMN ; ; MV_PLANS ; NO ; ; ; 241928ZFEB98 ; { 
05RD4; ; 52SEQ203 076 ; 

; RD5 ; ;RD1; ; 52SEQ210025 ; ; }$ 

UNIT; LOCATE ; TRK2 ; 52SEQ233160 ; $ 

UNIT ; LOCATE ; TRK4 ; 5 2 SEQ23 316 0;$ 

UNIT ; LOCATE ; TRK5 ; 52SEQ233 160 ; $ 

UNIT ; LOCATE ; TRK6 ; 5 2 SEQ2 33160;$ 

UNIT ; LOCATE ; TRK8 ; 52SEQ23 3 160;$ 

UNIT ; LOCATE ; TRK9 ; 5 2 SEQ2 33160;$ 

UNIT ; MISSION ; TRK2 ; MOVE; COLUMN; ; MV_PLAN S ; NO ; ; ; 241914ZFEB98 ; {0 
6RD3; ; 52SEQ221078 ; ; 

RD5 ; ; 52SEQ218066 ; ; RD1 ; ; 52SEQ210025 ; ; }$ 

UNIT ; MI SS I ON ; TRK4 ; MOVE; COLUMN; ; MV_PLANS ; NO ; ; ; 241917ZFEB98 ; {0 
6RD3 ; ; 52SEQ221078 ; ; 

RD5 ; ; 52SEQ218066 ; ;RD1; ; 52SEQ210025 ; ; }$ 

UNIT ; MISSION; TRK5 ; MOVE; COLUMN; ; MV_PLANS ; NO ; ; ; 241920ZFEB98 ; {0 
6RD3 ; ; 52SEQ221078 ; ; 

RD5 ; ; 52SEQ218066 ; ;RD1; ; 52SEQ210025 ; ; }$ 

UNIT ; MISSION; TRK6; MOVE; COLUMN; ; MV_PLANS ; NO ; ; ; 241924ZFEB98 ; {0 
6RD3 ; ; 52SEQ221078 ; ; 

RD5 ; ; 52SEQ218066 ; ; RD1 ; ; 52SEQ210025 ; ; }$ 
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UNIT ; MISS ION ;TRK8; MOVE /COLUMN; ; MV_PLANS ; NO ; ; ; 241927ZFEB98 ; {0 
6RD3 ; ; 52SEQ221078 ; / 

RD5 ; ; 5 2 SEQ2 180 66; ;RD1; ; 52SEQ210025 ; ;}$ 

UNIT ; MI SS ION ;TRK9; MOVE /COLUMN; ; MV_PLANS ; NO ; ; ; 241929ZFEB98 ; {0 
6RD3 ; ; 52SEQ221078 ; ; 

RD5 ; ; 52SEQ218066 ; ;RD1; ; 52SEQ210025 ; ; }$ 

a2c2_red_mines 

CE; CONSTRUCT /MINES; ; /OBSTACLE /MINE; AG/M-FLD-AP- 
LOW; { 04 52SEQ20 6 Oil ; 52SEQ2 12 004 ; 

52SEQ2 07002 ; 52SEQ2 01009 ; }$ 

a2r,2 -r«=>H 

UNIT7DEFINE ; HILL_DEFENSE ; AG ; INFANTRY / TEAM ; 52SEQ2 85 11 8 ; AGCON_ 
1 / ; S IMULATED ; FALSE ; NO ; $ 

UNIT ; DEFINE ; NB_DEFENSE ; AG ; INFANTRY; TEAM ; 52SEQ2 69087; AGCON_l ; 
; SIMULATED ; FALSE ; NO ; $ 

UNIT ; DEFINE ; SB_DEFENSE ; AG ; INFANTRY; TEAM ; 52SEQ2 23 02 0 ; AGCON_l ; 
; S IMULATED ; FALSE ; NO ; $ 

UNIT ; DEFINE ; PORT_DEFENSE ; AG ; INFANTRY ; TEAM ; 52SEQ3 28122; AGCON_ 
1 ; ; SIMULATED ; FALSE ; NO ; $ 

UNIT ; DEFINE ; AIRPORT_DEFENSE ; AG ; INFANTRY ; TEAM ; 52 SEP 145983 ; AGC 
ON_l ; ; S IMULATED ; FALSE ; NO ; $ 

ASSETS ; UPDATE ; NB_DEFENSE ; TROOPS ; { 0 1 8 ; HEALTHY ; } $ 

ASSETS ; UPDATE ; SB_DEFENSE ; TROOPS ; { 0 1 8 ; HEALTHY ; } $ 

ASSETS ; UPDATE ; AIRPORT_DEFENSE ; TROOPS ; { 0 1 8 ; HEALTHY ; } $ 

ASSETS; UPDATE ;HILL_DEFENSE; TROOPS; { 0 1 8 ; HEALTHY ; }$ 

ASSETS /UPDATE; PORT_DEFENSE; TROOPS; {018 /HEALTHY; }$ 

ASSETS ; UPDATE ; SB_DEFENSE ; WATER ; 5 0 0 ; $ 

ASSETS ; UPDATE ; NB_DEFENSE ; WATER ; 5 0 0 ; $ 

ASSETS ; UPDATE ; H I LL_DE FEN S E ; WATER; 500;$ 

ASSETS ; UPDATE ; PORT_DEFENSE ; WATER ; 50 0 ; $ 

ASSETS ; UPDATE ; AIRPORT_DEFENSE ; WATER ; 5 0 0 ; $ 

ASSETS ; UPDATE ; NB_DEFENSE ; RATIONS ; 2 0 0 ; $ 

ASSETS ; UPDATE ; SB_DEFENSE ; RATIONS ; 20 0 ; $ 

ASSETS ; UPDATE ; AIRPORT_DEFENSE ; RATIONS ; 2 0 0 ; $ 

ASSETS ; UPDATE ; PORT_DEFENSE ; RATIONS ; 2 0 0 ; $ 

ASSETS ; UPDATE ; HILL_DEFENSE ; RATIONS ; 2 0 0 ; $ 

ASSETS ; UPDATE ; NB_DEFENSE ; ASSET ; { 02M- 16 ; 3 ; OPERATIONAL ; SA- 
BALL ; 1 0 0 0 ; OPERATIONAL ; } $ 

ASSETS ; UPDATE ; SB_DEFENSE ; ASSET ; { 02M- 16 ; 3 ; OPERATIONAL ; SA- 
BALL ; 1 0 0 0 ; OPERATIONAL ; } $ 

ASSETS ; UPDATE ; AIRPORT_DEFENSE ; ASSET ; { 02M- 6 ; 3 ; OPERATIONAL ; SA- 
BALL; 1000 /OPERATIONAL; }$ 

ASSETS ; UPDATE ; H I LL_DE FENS E /ASSET ; { 02M- 16 ; 3 ; OPERATIONAL ; SA- 
BALL; 1000 /OPERATIONAL ; }$ 

ASSETS ; UPDATE ; PORT_DEFENSE ; ASSET ; { 02M- 16 ; 3 ; OPERATIONAL ; SA- 
BALL; 10 00 /OPERATIONAL; }$ 

a2r;2 snf 
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UNIT ; DEFINE ; P5_S0F ; LF ; ENGINEER; PLATOON ; 52SEQ2 170 94 ; MANCON_6 ; 
; S IMULATED ; FALSE ; YES ; USMC ; ENG_BRIDGE ; $ 

a2c2_p5_eng 

UNIT ; DEFINE ; P5_ENG; LF ; ENGINEER; COMPANY; 52SEQ2110 81 ; MANCON_6 ; 
; S IMULATED ; FALSE ; YES ; USMC ; CMB_ENG ; $ 

a2c2_p5_casl 

AIRCRAFT ; DEFINE ; FA- 18 ; P1_CV1_AIRSQUAD ; 0 00 2 ; QUANTITY ; 2 ; $ 

a2c2_p4_vfl 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIR_SQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 

a2c2 _p4_niv22_p4_lhal 

AIRCRAFT ; DEFINE ;MV- 22 ; P4_LHA1_AIRSQUAD ; 2222 ; QUANTITY; 1 ; $ 
a2c2_p4_mv22_p2_lpdl 

AIRCRAFT ; DEFINE ; MV- 2 2 ; P2_LPD1_AIRSQUAD ; 2 22 2 ; QUANTITY ; 1 ; $ 

a2c2_p4_xned2_lpdl 

AIRCRAFT; DEFINE ;UH- ; P2_LPD1_AIRSQUAD ; 5555; INDIVIDUAL; {Oil; }$ 
a2c2_p4_med2_lhal 

AIRCRAFT ; DEFINE ; UH- 1 ; P4_LHA1_AIRSQUAD ; 5555 ; INDIVIDUAL ; 

{Oil; }$ 



a2 c2_p4_medl_lhal 

AIRCRAFT ; DEFINE ; UH- 1 ; P4_LHA1_AIRSQUAD; 5555 ; INDIVIDUAL; 
{Oil; }$ 



a2c2_p4_lhal 

UNIT ; DEFINE ; P4_LHA1 ; LF ; SHIP ; COMPANY ; 52 SEQ2 60 000; MANCON_5 ; ; SI 
MULATED ; FALSE ; YES ; USN ; LHA; $ 

UNIT; DEFINE; P4_LHA1_AIRSQUAD ; LF ; AIR_SQUADRON ; COMPANY; P4_LHA1 
; AI RCON ; ; S IMULATED ; FALSE ; YES ; USMC ; MAS S ; $ 

UNIT; DEFINE; P4_LHA1_AIRSUPPLY; LF ; SUPPLY; SQUADRON; P4_LHA1 ; AIR 
CON ; ; S I MULATED ; FALSE ; NO ; $ 

ASSETS; UPDATE ;P4_LHA1_AIRSUPPLY; TROOPS; { 0150 ;HEALTHY; }$ 
ASSETS ; UPDATE ; P4_LHA1_AIRSUPPLY ; FUEL ; 1 0 0 0 0 0 0 ; $ 

ASSETS ; UPDATE ; P4_LHA1_AIRSUPPLY; RATIONS ; 50 0 0 ; $ 

ASSETS ; UPDATE ; P4_LHA1_AIRSUPPLY ; WATER ; 5 0 0 0 0 ; $ 

AIRFIELD ; DEFINE ; P4_LHA1 ; P4_LHA1 ; OPEN; ; P4_LHA1_AIRSUPPLY ; { 0 IP 
4 _LHA1_A I RSQUAD ; } { 0 0 ; } $ 

a2c2_p4_inf 2_p4_lhal 

UNIT ; DEFINE; P4_INF2 ; LF ; INFANTRY; PLATOON; P4_LHA1 ; MANCON_5 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; IFY_3 ; $ 

a2c;2 p4_inf 2_p2_lpdl 

UNIT7DEFINE; P4_INF2 ;LF; INFANTRY; PLATOON; P2_LPD1 ; MANCON_5 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; IFY_3 ; $ 
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a2c2_p4_inf l_p4_lhal 

UNIT ; DEFINE ; P4_INF1 ; LF ; INFANTRY ; PLATOON ; P4_LHA1 ; MANCON_5 ; ; SI 
MULATED ; FALSE ; YES ; 

USMC ; I FY_3 ; $ 

a2c2_p4_inf l_p2_lpdl_southbeach 
AIR_MISSION; DEFINE ; LPD_LAND_P4_INF1_SB ; MV- 
22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1SB ; MEDIUM ; UNIT_DROP / } $ 

SERIAL ; DEFINE ; LPD_LAND_P4_INF1_SB ; LF ; P2_LPD1 ; USE_OF_AI RCRAFT 
; { 01P4_INF1 ; } SB ; 

MV- 22 ; 1 ; $ 

SERIAL /ASSOCIATE ; LPD_LAND_P4_INF1_SB ; LPD_LAND_P4_INF1_SB ; $ 

a2c2_p4_inf l_p2_lpdl_nortlibeach 
A I R_M I S S I ON ; DE F I NE ; L PD_LAND_P4 _I NF 1_NB ; MV - 
22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P4_INF1_NB ; LF ; P2_LPD1 ; USE_OF_A I RCRAFT 
; {01P4_INF1; }NB; 

MV- 22 ; 1 ; $ 

SERIAL /ASSOCIATE / LPD_LAND_P4_INF1_NB / LPD_LAND_P4_INF1_NB / $ 
a2c2_p4_inf l_p2_lpdl 

UNIT / DEFINE / P4_INF1 / LF / INFANTRY / PLATOON / P2_LPD1 / MANCON_5 / / SI 
MULATED / FALSE / YES / 

USMC; IFY_3 / $ 

a2e2_p4_cas2 

AIRCRAFT ; DEFINE ; FA- 1 8 ; P1_CV1_AIRSQUAD ; 0 0 0 2 ; QUANTITY ; 2 / $ 
a2c2_p4_casl 

AIRCRAFT ; DEFINE ; FA- 18 ; P1_CV1_AIRSQUAD ; 0 0 02 ; QUANTITY / 2 ; $ 

a2 c 2_p4_ahl - l^p2_.lpdl 

AIRCRAFT /DEFINE ; AH-1W; P2_LPD1_AIRSQUAD ; 4444 ; QUANTITY; 2 ; $ 
AIRCRAFT ; DEFINE ; AH- 1W ; P2_LHA1_AIRSQUAD ; 4 4 4 4 ; QUANTITY / 2 ; $ 



a2r2 p4 aaavl on_j>4 lhal 

UNIT7DEFINE ; P4_AAAV1 ; LF ; ASSAULT_AMPHIB IAN ; PLATOON ; P4_LHA1 ; MA 
NCON_5 ; ; SIMULATED; 

FALSE ; YES ; USMC ; AAV ; $ 

a2n2_p4 aaavl on_p2_lhal 

UNIT7DEFINE ; P4_AAAV1 ; LF ; ASSAULT_AI4PHIB IAN ; PLATOON ; P2_LHA1 ; MA 
NCON_5 ; / SIMULATED ; 

FALSE ; YES ; USMC ; AAV ; $ 



a2fi2 p8 vfl 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIR_SQUAD ; 0 0 0 1 / QUANTITY / 2 ; $ 
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a2c2_p3^sof 

UNIT; DEFINE ; P3_S0F ; LF ; ENGINEER; PLATOON; 52SEQ2170 94 ; MANCON_4 ; 
; S IMULATED ; FALSE ; 

YES ; USMC ; ENG_BRIDGE ; $ 

a2c2_p3_mv22b_p3_lpdl 

AIRCRAFT ; DEFINE ; MV-22 ; P3_LPD1_AIRSQUAD ; 2222 ; QUANTITY ; 1 ; $ 



a2c2_p3_mv22b_p2_lpdl 

AIRCRAFT; DEFINE ; MV-22 ; P2_LPD1_AIRSQUAD; 2222 ; QUANTITY; 1 ; $ 
a2c2_p3_mv22a_p3_lpdl 

AIRCRAFT ; DEFINE; MV- 22 ;P3_LPD1_AIRSQUAD; 2222 ; QUANTITY; 1 ; $ 

a2.c2 -.p3_mv2 2 a_p2_lpdl 

AIRCRAFT ; DEFINE ; MV-22 ; P2_LPD1_AIRSQUAD ; 2222 ; QUANTITY ; 1 ; $ 

a2c2_p3_med2_lhal 

AIRCRAFT ; DEFINE ; UH- 

1;P2_LHA1_AIRSQUAD; 5555; INDIVIDUAL; {Oil; }$ 

a2c2_p3_medl_lpdl 
AIRCRAFT ; DEFINE ; UH- 

1 ; P3_LPD1_AIRSQUAD ; 5555 ; INDIVIDUAL; {Oil; }$ 

a2c2_p3_medl_lhal 
AIRCRAFT ; DEFINE ; UH- 

1 ; P2_LHA1_AIRSQUAD ; 5555 ; INDIVIDUAL ; { Oil ; } $ 

a2c2._p3_lpdl 

UNIT; DEFINE ; P3_LPD1 ; LF ; SHIP ; COMPANY ; 52SEQ284 03 0 ; MANCON_4 ; ; SI 
MULATED ; FALSE ; YES ; CIS ; LPD_AG_CLASS ; $ 

UNIT ; DEFINE ; P3_LPD1_AIRSQUAD ; LF ; A I R_SQUADRON ; COMPANY; P3_LPD1 
; AIRCON ; ; SIMULATED ; FALSE ; YES ; USMC ; MASS ; $ 

UNIT; DEFINE ; P3_LPD1_AIRSUPPLY; LF ; SUPPLY; SQUADRON; P3_LPD1 ;AIR 
CON ; ; SIMULATED ; FALSE ; NO ; $ 

ASSETS; UPDATE ; P3_LPD1_AIRSUPPLY; TROOPS; { 0150 ; HEALTHY; } $ 
ASSETS ; UPDATE ; P3_LPD1_AIRSUPPLY ; FUEL ; 1 0 0 0 0 0 0 .; $ 

ASSETS ; UPDATE ; P3_LPD1_AIRSUPPLY ; RATIONS ; 5 0 0 0 ; $ 

ASSETS ; UPDATE ; P3_LPD1_AIRSUPPLY ; WATER ; 5 0 0 0 0 ; $ 

AIRFIELD ; DEFINE ; P3_LPD1 ; P3_LPD1 ; OPEN; ; P3_LPD1_AIRSUPPLY; 

{ 0 1P3_LPD1_AIRSQUAD ; } {00; }$ 



a2c2_p3_inf 5_p2_lhal 

UNIT; DEFINE ; P3_INF5 ; LF ; INFANTRY; PLATOON; P2_LHA1 ; MANCON_4 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; HMG ; $ 

a2c2_p3_in£l. : .p2_lhal_SQUthbeach 
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AIR_MI SS ION ; DEFINE ; LHA_LAND_P3_INF4_SB ; MV- 
2 2 ; 1 ; P2_LHA1_AIRSQUAD ; P2_LHA1 / / / ; STS ; 

TAKE_OFF ; ; { 0 1SB ; MEDIUM ; UNI T_DROP ; } $ 

SERIAL ; DEFINE ; LHA_LAND_P3_INF4_SB ; LF ; P2_LHA1 ; USE_OF_AIRCRAFT 
; { 01P3_INF4 ; }SB ;MV-22 ; 1 ; $ 

SERIAL /ASSOCIATE / LHA_LAND_P3_INF4_SB ; LHA_LAND_P3_INF4_SB ; $ 

a2c2_p3_inf4_p2_lhal_northbeach 
AIR_MISSION; DEFINE ; LHA_LAND_P3_INF4_NB ; MV- 
22 ; 1 ; P2_LHA1_AIRSQUAD ; P2_LHA1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LHA_LAND_P 3 _ I NF 4 _NB ; LF ; P2_LHA1 ; USE_OF_AIRCRAFT 
; { 01P3_INF4 ; }NB ; MV-22 ; 1 / $ 

SERIAL /ASSOCIATE / LHA LAND P 3 I NF 4 NB / LHA LAND P 31 NF 4 NB / $ 



a2r.2 p3 inf4 p2 lhal 

UNIT7DEFINE / P3_INF4 / LF / INFANTRY / PLATOON / P2_LHA1 / MANCON_4 //SI 
MULATED / FALSE / YES / 

USMC / IFY_3 ; $ 

a2c2_p3_inf 3_p2_lpdl_southbeach 
AIR_MISS ION/ DEFINE / LPD_LAND_P3_INF3_SB / MV- 
22 / 1 / P2_LPD1_AIRSQUAD / P2_LPD1 / / / / STS / 

TAKE_OFF / / { 0 1SB / MEDIUM / UNIT_DROP / } $ 

SERIAL / DEFINE / LPD_LAND_P3_INF3_SB ; LF / P2_LPD1 / USE_OF_AIRCRAFT 
/ {01P3_INF3/ } SB /MV-22/ l/$ 

SERIAL/ ASSOCIATE / LPD_LAND_P3_INF3_SB/LPD LAND P3_INF3 SB/$ 



a2c2_p3_inf 3_p2_lpdl_northbeach 
AIR_MISSION/ DEFINE / LPD_LAND_P3_INF3_NB / MV- 
22 / 1 / P2_LPD1_AIRSQUAD / P2_LPD1 / / / / STS / 

TAKE_OFF / / { 01NB / MEDIUM / UNIT_DROP / } $ 

SERIAL / DEFINE / LPD_LAND_P3_INF3_NB / LF / P2_LPD1 / USE_OF_AIRCRAFT 
/ {01P3_INF3/ } NB / MV- 2 2 / 1 / $ 

SERIAL /ASSOCIATE / LPD_LAND_P3_INF3_NB / LPD_LAND_P 3 _ I NF 3 _NB / $ 
a2c2_p3_inf 3_p2_lpdl 

UNIT/DEFINE/ P3_INF3 /LF/ INFANTRY/ PLATOON/ P2_LPD1 / MANCON_4 / /SI 
MULATED / FALSE / YES / USMC / I FY_3 / $ 

a2c2 ^ p3_in£2_p3_lpdl_southbeach 

AIR_MISSION/ DEFINE / LPD_LAND_P3_INF2_SB / MV- 
22 / 1 / P3_LPD1_AIRSQUAD / P3_LPD1 / / / / STS / 

TAKE_OFF / / { 0 1 SB / MEDIUM/ UNI T_DROP / } $ 

SERIAL / DEFINE / LPD_LAND_P3_INF2_SB / LF ; P3_LPD1 ; USE_OF_AIRCRAFT 
/ {01P3_INF2/ } SB /MV-22 / 1 / $ 

SERIAL / ASSOCIATE / LPD_LAND_P3_INF2_SB / LPD_LAND_P3_INF2_SB / $ 

a2c2_p3_inf 2_p3_lpdl_nort:hbeach 
AIR_MISSION / DEFINE / LPD_LAND_P3_INF2_NB / MV- 
22 / 1 / P3_LPD1_AIRSQUAD / P3_LPD1 / / / / STS / 
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TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P3_INF2_NB ; LF ; P3_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF2 ; } NB ; MV- 2 2 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LPD_LAND_P3_INF2_NB ; LPD_LAND_P3_INF2_NB ; $ 

a2c2_p3_inf 2_p2_lpdl_southbeach 
AIR_MISSION; DEFINE ; LPD_LAND_P3_INF2_SB ;MV- 
2 2 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1 SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P3_INF2_SB ; LF ; P2_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF2 ; } SB ; MV- 2 2 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LPD_LAND_P3_INF2_SB ; LPD_LAND_P3_INF2_SB ; $ 



a2c2_p3_inf 2_p2_lpdl_northbeach 
AIR_MISSION; DEFINE ; LPD_LAND_P3_INF2_NB ;MV- 
22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P3_INF2_NB ; LF ; P2_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF2 ; }NB ;MV-22 ; 1 ; $ 

SERIAL; ASSOCIATE ;LPD_LAND_P3_INF2_NB;LPD_LAND_P3_INF2_NB ; $ 
a2c2_p3_inf 2_p2_lpdl 

UNIT ; DEFINE ; P3_INF2 ; LF ; INFANTRY ; PLATOON ; P2_LPD1 ; MANCON_4 ; ; S I 
MULATED ; FALSE ; YES ; USMC ; IFY_3 ; $ 

a2c2_p3_inf l_p3_lpdl_southbeach 

AIR_MI SS ION ; DEFINE ; LPD_LAND_P3_INF1_SB ; MV- 

22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 01SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P3_INF1_SB ; LF ; P3_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF1 ; } SB ;MV-22 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LPD_LAND_P3_INF1_SB ; LPD_LAND_P3_INF1_SB ; $ 

a2c2_p3_inf l_p3_lpdl_northbeach 
AIR_MISSION; DEFINE ; LPD_LAND_P3_INF1_NB ; MV- 
22 ; 1 ; P3_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P3_INF1_NB ; LF ; P3_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF1 ; }NB ;MV-22 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LPD_LAND_P3_INF1_NB ; LPD_LAND_P 3 _ I N F 1_NB ; $ 

a2c2_p3_infl_p3_lpdl 

UNIT; DEFINE ; P3_INF1 ; LF; INFANTRY; PLATOON; P3_LPD1 ;MANCON_4 ; ; SI 
MULATED ; FALSE ; YES ; USMC ; IFY_3 ; $ 

a2c2_p3_infl_p2_lpdl_SQUthbeach 
AIR_MISSION ; DEFINE ; LPD_LAND_P3_INF1_SB ; MV- 
22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 0 1SB ; MEDIUM ; UNIT_DROP ; } $ 
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SERIAL ; DEFINE ; LPD_LAND_P3_INF1_SB ; LF ; P2_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF1 ; } SB ; MV- 22 ; 1 ; $ 

SERIAL /ASSOCIATE; LPD_LAND_P3_INF1_SB ; LPD_LAND_P3_INF1_SB ; $ 

a2c2_p3_inf l_p2_lpdl_northbeach 
AIR_MISSION; DEFINE; LPD_LAND_P3_INF1_NB ;MV- 
22 ; 1 ; P2_LPD1_AIRSQUAD ; P2_LPD1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 01NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LPD_LAND_P 3 _ I NF 1_NB ; LF ; P2_LPD1 ; USE_OF_AIRCRAFT 
; { 01P3_INF1 ; }NB;MV-22 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LPD_LAND_P3_INF1_NB;LPD_LAND_P3_INF1_NB; $ 
a2c2_p3_inf l_p2_lpdl 

UNIT ; DEF INE ; P3_INF1 ; LF ; INFANTRY ; PLATOON ; P2_LPDl ; MANCON_4 ; ; S I 
MULATED ; FALSE ; YES ; USMC ; IFY_3 ; $ 

a2c2_p3_eng 

UNIT ; DEFINE ; P3_ENG; LF ; ENGINEER; COMPANY ; 52SEQ223 087 ; MANCON_4 ; 
; S IMULATED ; FALSE ; YES ; USMC ; CMB_ENG ; $ 



a2c2_p3_casl 

AIRCRAFT ; DEFINE ; FA- 1 8 ; P1_CV1_AIR_SQUAD ; 0 0 02 ; QUANTITY ; 2 ; $ 
a2c2_p3_aaav3_on_p2_lpdl 

UNIT ; DEFINE; P3_AAAV3 ; LF ; ASS AULT_AMPH I B I AN ; PLATOON; P2_LPD1 ;MA 
NCON_4 ; ; SIMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2c2_.p3_aaav2_on _j ?2_lhal 

UNIT ; DEFINE ; P3_AAAV2 ; LF ; ASSAULT_AMPH I B I AN ; PLATOON ; P2_LHA1 ; MA 
NCON_4 ; ; SIMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2c2 p3 aaavl on_p3 lpdl 

UNIT7DEFINE ; P3_AAAV1 ; LF ; AS S AULT_AM PH I B I AN ; PLATOON ; P3_LPD1 ; MA 
NCON_4 ; ; SIMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2c2_p3_aaavl_on_p2_lhal 

UNIT ; DEFINE ; P3_AAAV1 ; LF ; ASS AULT_AMPHI B IAN ; PLATOON ; P2_LHA1 ; MA 
NCON_4 ; ; S IMULATED ; FALSE ; YES ; USMC ; AAV ; $ 

a2n2_p2 vfl 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIRSQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 
a2c2_p2_sof 

UNIT /DEFINE ; P2_SOF ; LF ; ENGINEER; PLATOON; 52SEQ217094 ;MANCON_3 ; 
/SIMULATED ; FALSE ; YES ; USMC ; ENGJ3RIDGE ; $ 

a2 c 2_ p 2_mv2 2. _p 2.--lhal 

AIRCRAFT /DEFINE; MV-22 ; P2_LHA1_AIRSQUAD; 2222 /QUANTITY; 1; $ 

a2c2_p2_med3_lhal 
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AIRCRAFT ; DEFINE ; UH- 

1 ; P2_LHA1_AIRSQUAD; 5555 ; INDIVIDUAL; { 013 ; } $ 

a2c2_p2_med2_lhal 
AIRCRAFT ; DEFINE ; UH- 

1 ; P2_LHA1_AIRSQUAD ; 5555 ; INDIVIDUAL ; { 0 12 ; } $ 

a2c2_p2_medl_lpdl 
AI RCRAFT ; DEF INE ; UH - 

1 ; P2_LPD1_AIRSQUAD; 5555 ; INDIVIDUAL; { Oil ; } $ 
a2c2_p2_lpdl 

UNIT ; DEFINE ; P2_LPD1 ; LF ; SHIP ; COMPANY ; 52SEQ2 84 03 0 ; MANCON_3 ; ; SI 
MULATED ; FALSE ; YES ; CIS ; LPD_AG_CLASS ; $ 

UNIT ; DEFINE ; P2_LPD1_AIRSQUAD ; LF ; AI R_SQUADRON ; COMPANY ; P2_LPD1 
; AI RCON ; ; S IMULATED ; FALSE ; YES ; USMC ; MASS ; $ 

UNIT ; DEFINE ; P2_LPD1_AIRSUPPLY ; LF ; SUPPLY; SQUADRON ; P2_LPD1 ; AIR 
CON ; ; SIMULATED ; FALSE ; NO ; $ 

ASSETS ; UPDATE ; P2_LPD1_AIRSUPPLY; TROOPS ; { 0 1 5 0 ; HEALTHY ; } $ 
ASSETS ; UPDATE ; P2_LPD1_AIRSUPPLY ; FUEL ; 1 0 0 0 0 0 0 ; $ 

ASSETS ; UPDATE ; P2_LPD1 ; FUEL ; 1 0 0 0 0 0 0 ; $ 

ASSETS ; UPDATE ; P2_LPD1_AIRSUPPLY; RATIONS ; 50 00 ; $ 

ASSETS ; UPDATE ; P2_LPD1_AIRSUPPLY ; WATER ; 5 0 0 0 0 ; $ 

AIRFIELD ; DEFINE ; P2_LPD1 ; P2_LPD1 ;OPEN; ; P2_LPD1_AIRSUPPLY ; { 01P 
2 _LPD 1_AI RSQUAD ; } { 00 ; } $ 

a2c2_p2_lhal 

UNIT ; DEF INE ; P2_LHA1 ; LF ; SHIP ; COMPANY ; 52 SEQ2 600 0 0; MANCON_3 ; ; SI 
MULATED ; FALSE ; YES ; USN ; LHA ; $ 

UNIT; DEFINE; P2_LHA1_AI RSQUAD ; LF ; AI R_SQUADRON ; COMPANY; P2_LHA1 
; AIRCON ; ; S IMULATED ; FALSE ; YES ; USMC ; MASS ; $ 

UNIT ; DEF INE ; P2_LHA1_AIRSUPPLY ; LF ; SUPPLY ; SQUADRON ; P2_LHA1 ; AIR 
CON ; ; SIMULATED ; FALSE ; NO ; $ 

ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY; TROOPS ; { 0150 ; HEALTHY; }$ 
ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; FUEL ,-1000000;$ 

ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY; RATIONS ; 5000 ; $ 

ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; WATER ; 5 0 0 0 0 ; $ 

AIRFIELD; DEFINE; P2_LHA1 ; P2_LHA1 ;OPEN; ; P2_LHA1_AIRSUPPLY; { 01P 
2_LHA1_AIRSQUAD ; } { 0 0 ; } $ 

a2c2_p2_inf l_p2_lhal_southbeach 

AI R_M I S S I ON ; DEF INE ; LHA_LAND_P2_INF 1_SB ; MV- 

22 ; 1 ; P2_LHA1_AIRSQUAD ; P2_LHA1 ; ; ; ; STS ; 

TAKE_OFF ; ; { 01 SB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LHA_LAND_P2_INF1_SB ; LF ; P2_LHA1 ; USE_OF_AI RCRAFT 
; { 01P2_INF1 ; } SB ;MV-22 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LHA_LAND P2_INF1_SB ; LHA_LAND_P2_INF1_SB ; $ 



a2c2_p2_inf l_p2_lhal_northbeach 
AIR_MISS ION; DEFINE ; LHA_LAND_P 2 _ I NF 1 _NB ; MV- 
22 ; 1 ; P2LHA1_AI RSQUAD ; P2_LHA1 ; ; ; ; STS ; 
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TAKE_OFF ; ; { 0 1NB ; MEDIUM ; UNIT_DROP ; } $ 

SERIAL ; DEFINE ; LHA_LAND_P2_INF1_NB ; LF ; P2_LHA1 ; USE_OF_AI RCRAFT 
; { 01P2_INF1 ; }NB ;MV-22 ; 1 ; $ 

SERIAL ; ASSOCIATE ; LHA_LAND_P2 _ I NF 1_NB ; LHA__LAND_ P 2 _ I N F 1 _NB ; $ 



a2c2_p2_infl_p2^1hal 

UNIT; DEFINE ;P2_INF1;LF; INFANTRY ; PLATOON; P2_LHA1 ; MANCON_3 ; ;SI 
MULATED ; FALSE ; YES ; USMC ; I FY 3 ; $ 



a2r;2_p2_eng 

UNItTdEFINE ; P2_ENG ; LF ; ENGINEER ; COMPANY ; 52SEQ2 1108 1 ; MANCON_3 ; 
; SIMULATED ; FALSE ; YES ; USMC ; CMB_ENG ; $ 

a2c2_p2_ddg 2 

UNIT ; DEFINE ; P2_DDG2 ; LF ; SHIP ; COMPANY ; 52SEQ4 55151; MANCON_3 ; ; SI 
MULATED ; FALSE ; YES ; USN ; BURKE CLASS ; $ 



a2ci2 p2 ddg l 

UNItTdEFINE ; P2_DDG1 ; LF ; SHI P ; COMPANY ; 52 SEQ4 89065; MANCON_3 ; ; SI 
MULATED ; FALSE ; YES ; USN ; BURKE_CLASS ; $ 

a2c2_p2_casl 

AIRCRAFT; DEFINE; FA- 18 ; P1_CV1_AIR_SQUAD ; 0002 ; QUANTITY; 2 ; $ 
a2c2_p2_aaavl_Qn_p2_lhal 

UNIT ; DEFINE ; P2_AAAV1 ; LF ; ASSAULT_AMPHIB IAN ; PLATOON ; P2_LHA1 ; MA 
NCON_3 ; ; SIMULATED ; FALSE ; YES ; USMC ; AAV; $ 

a2c2_pl_vf 4 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIR_SQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 
a2c2_pl_vf 3 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIR_SQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 
a2r?2 pi vf2 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIR_SQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 

a2c2_pl_y£l 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIR_SQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 



a2r;2 pi ffg 2 

UNItTdEFINE ; P1_FFG2 ; LF ; SHIP ; COMPANY ; 52SEP33 8 94 9 ; MANCON_2 ; ; SI 
MULATED ; FALSE ; YES ; USN; P ERRY_CLAS S ; $ 

a2c2_pl_££gl 

UNIT ; DEFINE ; P1_FFG1 ; LF ; SHIP ; COMPANY; 52SEQ42 1115 ; MANCON_2 ; ; SI 
MULATED ; FALSE ; YES ; USN ; PERRY CLASS ; $ 



a2c2_pl_ddg l 
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UNIT ; DEFINE ; P1_DDG1 ; LF ; SHI P ; COMPANY ; 5 2SEP3 7 7 9 6 7 ; MANCON_2 ; ; SI 
MULATED ; FALSE ; YES ; USN; BURKE_CLASS ; $ 

a2c2_pl_cvl 

UNIT ; DEFINE ; P1_CV1 ; LF ; SHI P ; COMPANY ; 5 2 SEQ3 54 0 3 7 ; MANCON_2 ; ; SIM 
ULATED ; FALSE ; YES ; USN ; JFK_CLASS ; $ 

UNIT; DEFINE; P1_CV1_AIRSUPPLY; LF ; SUPPLY; COMPANY; P1_CV1 ; AIRCON 
; ; S IMULATED ; FALSE ; YES ; USMC ; MAT_SUP ; $ 

UNIT ; DEFINE ; P1_CV1_AIRSQUAD ; LF ; AIR_SQUADRON ; SQUADRON; P1_CV1 ; 
AIRCON ; ; S IMULATED ; FALSE ; YES ; USMC ; VMAAW ; $ 

AIRFIELD; DEFINE; P1_CV1 ; P1_CV1 ;OPEN; P1_CV1_AIRSUPPLY; P1_CV1_A 
IRSUPPLY; { 01P1_CV1_AIRSQUAD ; } { 00 ; } $ 

ASSETS ; UPDATE ; P1_CV1_AIRSQUAD ; ASSET ; { 04MK- 84 - 
BOMB ; 5 0 0 ; OPERATIONAL ; ZUNI -RKT-4 ; 

5 0 0 ; O PERAT I ONAL ; 2 0 MM - HE - AC ; 1000 00 ; O PERAT I ONAL ; MAVER I CK - TV - 
MSL ; 5 0 0 ; OPERATIONAL ; } $ 

ORD_LOAD ; DEFINE ; VF_AIR_ORD ; LF ; { 04MK- 84 -BOMB ; 8 ; Q ; MAVERICK-TV - 
MSL ; 8 ; Q ; ZUNI -RKT-4 ; 8 ; Q ; 2 0MM-HE -AC ; 1 0 0 0 ; NONE ; } $ 



a2c2_pl_cg l 

UNIT ; DEFINE ; P1_CG1 ; LF ; SHIP ; COMPANY ; 52 SEQ3 40014; MANCON_2 ; ; SIM 
ULATED ; FALSE ; YES ; USN ; BELKNAP_CLASS ; $ 

a2c2_pl_casl 

AIRCRAFT ; DEFINE ; FA- 18 ; P1CV1AIRSQUAD ; 0 0 0 2 ; QUANTITY ; 2 ; $ 



a2c2_p0_vf 4 

AIRCRAFT ; DEFINE ; F - 14 ; P1_CV1_AIRSQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 
a2c2_p0_vf 3 

AIRCRAFT ; DEFINE ; F - 1 4 ; P1_CV1_AIR SQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 
a2e:2_p0_vf 2 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIRSQUAD ; 0 0 01 ; QUANTITY ; 2 ; $ 
a2c2_p0_v£l 

AIRCRAFT ; DEFINE ; F - 14 ; P1_CV1_AIRSQUAD ; 0 0 0 1 ; QUANTITY ; 2 ; $ 

a2c2_pQ_tarps 

AIRCRAFT ; DEFINE ; F- 14 ; P1_CV1_AIRSQUAD ; 3333 ; QUANTITY; 2 ; $ 

a2c2_pQ_launch_tarps 
AIR_MISSION; DEFINE ; TARPS ; F- 

14 ; 2 ; P1_CV1_AIRSQUAD; PI CV1 ; ; ; ;RECON; { 04PHOTO; IR; 

SLAR; VISUAL; }TAKE_OFF; ;"{"0152SEQ3 530 53 ; MEDIUM; ORBIT; } $ 

a2c2_p0_cas2 

AIRCRAFT; DEFINE; FA-18 ; P1_CV1_AIR_SQUAD ; 0002 ; QUANT I TY ; 2 ; $ 
a2c2_p0_casl 

AIRCRAFT; DEFINE; FA- 18; PI CV1 AIR SQUAD; 0002 ; QUANTITY; 2 ; $ 
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a2c2_launch_p5_casl 
AI REMISSION; DEFINE ; P5_CAS1 ; FA- 

18 ; 2 ; P1_CV1_AIRSQUAD ; P1_CV1 ; ; ; P5_ENG ; CAS ; CAS_ORD ; 
; ; FALSE ;TAKE_OFF; ; { 0152SEQ3 06046 ; MEDIUM; ORBIT ; }$ 

a2e2_launch_p4_cag2 
AIR_MISSION; DEFINE ; P4_CAS2 ; FA- 

18 ; 2 ; P1_CV1_AIRSQUAD ; P1_CV1 ; ; ; P5_ENG ; CAS ; CAS_ORD ; 
; ; FALSE ;TAKE_OFF; ; { 0152SEP357997 /MEDIUM /ORBIT; }$ 



a2c2_launch_p4_casl 
AIR_MISSION;DEFINE; P4_CAS1 / FA- 

18 ; 2 ; P1_CV1_AIRSQUAD ; P1_CV1 / ; ; P5_ENG ; CAS ; CAS_ORD ; 

; ; FALSE ;TAKE_OFF; ; { 0152SEQ32 1022 /MEDIUM; ORBIT; }$ 

a2c2_launch_p3_casl 
AIR_MISSION; DEFINE; P3_CAS1; FA- 

18 ; 2 ; P1_CV1_AIRSQUAD; P1_CV1 ; ; ; P5_ENG ; CAS ; CAS_ORD ; 

; ; FALSE ; TAKE_OFF ; ; { 0152SEQ371072 /MEDIUM /ORBIT; }$ 

a2c2_launch_pl_cagl 

AIR_MISS ION; DEFINE ; P1_CAS1 ; FA- 

18 ; 2 ; P1_CV1_AIRSQUAD ; P1_CV1 ; ; ; P5_ENG ; CAS ; CAS_ORD ; 

; ; FALSE ; TAKE_OFF ; ; { 0152SEQ334058 /MEDIUM /ORBIT; }$ 

a2c2 _c reate_terrain 

CE ; CONSTRUCT ; RD1 ; ; ; IMPROVED_SURFACE ; ROAD ; AS PHLT - 2 - 
LANE; { 13 52SEQ32 512 7 ; 

52SEQ324121 ; 52SEQ317117 ; 52 SEQ3 09120 ; 52SEQ305117 ; 52SEQ303114 ; 
5 2 SEQ2 92105/52 SEQ2 69104 ; 52SEQ2 63102 ; 52SEQ255087 ; 52SEQ22206 9 ; 
52SEQ219066 ; 52SEQ210026 ; }$ 

CE ; CONSTRUCT ; RD2 ; ; ; IMPROVED_SURFACE ; ROAD ; AS PHLT - 2 - LANE ; 

{ 1752SEQ237077 ; 52SEQ238073 ; 52SEQ234063 ; 52SEQ237052 ; 52SEQ2340 
44; 

52SEQ236039 ; 52SEQ232026 ; 52SEQ224024 ; 52SEQ219018 ; 52SEQ214017 ; 
52SEQ213 014 ; 52SEQ2020 01 ; 52SEP194994 ; 52SEP1909 94 ; 52SEQ1830 04 ; 
52SEQ167000 ; 52SEP154985 ; }$ 

CE ; CONSTRUCT ; RD3 ; ; ; IMPROVED_SURFACE ; ROAD ; AS PHLT - 2 - 
LANE; { 1552SEQ235161 ; 52SEQ234158 ; 52SEQ235156 ; 52SEQ233155; 
52SEQ235150 ; 52SEQ234147 ; 52SEQ240140 ; 52SEQ239126 ; 52SEQ235119 ; 
52SEQ235109 ; 52SEQ230101 ; 52SEQ228100 ; 52SEQ227090 ; 52SEQ222080 ; 
52SEQ221079 ; } $ 

CE ; CONSTRUCT ; RD4 ; ; ; IMPROVED_SURFACE ; ROAD ; AS PHLT - 2 - LANE ; 
{0852SEQ12 8118 /52SEQ133 118 ; 52SEQ145110 ; 52SEQ145107 ; 52SEQ1490 
92; 

52SEQ172079 ; 52SEQ188084 ; 52SEQ202076 ; }$ 

CE ; CONSTRUCT ;RD 5; ; ; IMPROVED_SURFACE ; ROAD ; AS PHLT- 2 - LANE ; 

{ 0352SEQ221077 ; 52SEQ219066 ; 52SEQ204076 ; } $ 
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CE ; CREATE ; HILL ; NATURAL_TERRAIN ; MOUNTAIN ; MOUNTAIN ; { 0 6 5 2 SEQ2 8 4 
126 ; 52SEQ2 76122 ; 52SEQ2 75115 ; 52SEQ2 84111; 52SEQ294116 ; 52SEQ292 
125;}$ 

CE ; CREATE ; PORT ; STRUCTURE ; PORT- 
FACILITY; 52SEQ315116 ; 15 ; 4 0 ; 100 ; $ 

CE ; CREATE ; RVR1 ; NATURAL_TERRA I N ; RIVER ; RIVER ; 1 0 0 ; { 0 3 52 SEQ2 4 209 
0 ; 52SEQ223 076 ; 52SEQ213 087 ; } $ 

CE ; CREATE ; RVR2 ; NATURAL_TERRAIN ; RIVER ; RIVER ; 1 0 0 ; { 0 2 52 SEQ2 13 08 
7 ; 52SEQ196068 ; }$ 

CE ; CONSTRUCT ; BRIDGE1 ; ; ; IMPROVED_SURFACE ; BRIDGE ; CONCRETE - 
BRIDGE-A; 52SEQ203076 ;RVR1 ; $ 

CE ; CONSTRUCT ; BRIDGE2 ; ; ; IMPROVED_SURFACE ; BRIDGE ; CONCRETE - 
BRIDGE-A; 52SEQ221078 ;RVR2 ; $ 

a2c2_create_intel_blue 

UNIT; DEFINE; INTEL ; LF ; RECONNAISSANCE ; PLATOON; 52SEQ205092 ; INT_ 
CON_l ; ; S IMULATED ; TRUE ; YES ; USMC ; D I V_RECON ; $ 

ASSETS; UPDATE; INTEL; ASSET; { 01SENSOR- 1 ; 16 ; OPERATIONAL ; }$ 

a2c2_cas_ord 

ORD_LOAD ; DEFINE ; CAS_ORD ; LF ; { 02MK- 84 -LGB ; 3 2 ; Q ; MAVERICK- TV - 
MSL; 32 ; Q ; } $ 

ASSETS ; UPDATE ; P1_CV1_AIRSQUAD ; ASSET ; { 03MAVERICK-TV- 
MSL; 1000 ; OPERATIONAL ; 

NAPALM - BOMB ; 1 0 0 0 ; OPERATIONAL ; MK- 8 4 - LGB ; 1 0 0 0 ; OPERAT IONAL ; } $ 
a2c2_beaches_and_LZs 

BEACH; DEFINE; SOUTH_BCH ; LF ; 52SEQ23 0 006 ; 52SEQ24502 0 ; ; ;52SEQ232 
004 ;52SEQ249016;52SEQ23 7015; { 0352SEQ252014 ; 52SEQ236002 ;52SEQ 
252004; } ; ; ;$ 

BEACH ; DEFINE; NORTH_BCH ; LF ; 52SEQ2 68 065 ; 52SEQ2 89074 ; ; ;52SEQ2 69 
061 ;52SEQ2 92071 ;52SEQ27 9073; {03 52SEQ275060 ; 52SEQ293066 ; 52SEQ 
289054; } ; ; ;$ 

CHECKPOINT ; DEFINE ; NB ; 5 2 SEQ27 6 0 71 ; LF ; YES ; $ 

CHECKPO I NT ; DEF INE ; SB ; 5 2 SEQ23 5 0 12 ; LF ; YES ; $ 

a2c2_air field 

UNIT; DEFINE ; P2_LHA1_AIRSUPPLY; LF ; SUPPLY; SQUADRON; P2_LHA1 ; AIR 
CON ; ; S IMULATED ; FALSE ; NO ; $ 

ASSETS; UPDATE ;P2_LHA1_AIRSUPPLY; TROOPS; { 0150 ; HEALTHY; } $ 
ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY ; FUEL ; 1 0 0 0 0 0 0 ; $ 

ASSETS ; UPDATE ; P2_LHA1_AIRSUPPLY; RATIONS ; 5000 ; $ 

ASSETS ; UPDATE; P2_LHA1_AIRSUPPLY; WATER; 50000 ; $ 

AIRFIELD ; DEFINE ; P2_LHA1 ; P2_LHA1 ; OPEN; ; P2_LHA1_AIRSUPPLY ; { 0 IP 
2_LHA1_AIRSQUAD ; } { 0 0 ; } $ 

Master Batch Files 

A2C2_A0 

a2c2_create_terrain 
a2c2 beaches and LZs 
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a2c2_red_def ense 

a2c2_trucks_create 

a2c2_run_t rucks 

a2c2_pl_cgl 

a2c2_pl_cvl 

a2c2_pl_ddgl 

a2c2_pl_f fgl 

a2c2_pl_f fg2 

a2c2_p2_lhal 

a2c2_p2_lpdl 

a2 c2_j?2_mv2 2_p2_lhal 

a2c2_p3_mv22a_p2_lpdl 

a2c2_p3_mv22b_p2_lpdl 

a2c2_p3_aaavl_on_p2_lhal 

a2c2_p3_aaav2_on_p2_lhal 

a2c2_p3_aaav3_on_p2_lpdl 

a2c2_pO_tarps 

a2c2_p0_vf 1 

a2c2_p0_vf 2 

a2c2_p0_vf 3 

a2c2_p0_vf 4 

a2c2_pl_casl 

a2c2_p2_inf l_p2_lhal 

a2c2_p2_medl_lpdl 

a2 c2_p2_med2_lhal 

a2c2_p2_med3_lhal 

a2c2_p3_inf l_p2_lpdl 

a2c2_p3_inf 2_p2_lpdl 

a2c2_p3_inf 3_p2_lpdl 

a2c2_p3_inf4_p2_lhal 

a2c2_p3_eng 

a2c2_p4_casl 

a2c2_p4_cas2 

a2c2_p5_casl 

a2c2_p5_eng 

a2c2_p5_sof 

a2 c2_p4_ahl - l_p2_lpdl 

a2c2 cas ord 
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APPENDIX B 



UNIT LISTINGS 



DM 


Asset 


AO 


AOpost 


A1 


A2 


o 

< 


AO 'post 


Player 0 


SAT 


1 


1 


1 


1 


1 


1 




VF 


4 


3 


0 


0 


0 


0 




SMC 


0 


0 


1 


0 


0 


0 




CAS 


0 


0 


1 


2 


0 


0 




TARPS 


1 


0 


0 


0 


1 


0 


Player 1 


CG 


1 


1 


1 


1 


1 


1 




FFG 


2 


1 


1 


1 


2 


1 




CAS 


1 


1 


0 


0 


1 


1 




DDG 


0 


0 


1 


1 


0 


0 




VF 


0 


0 


1 


0 


4 


3 




CV 


0 


0 


1 


1 


1 


1 




SMC 


0 


0 


0 


1 


0 


0 


Player 2 


MV22 


1 


1 


0 


0 


1 


1 




SMC 


2 


1 


0 


0 


2 


1 




DDG 


2 


1 


0 


0 


2 


1 




INF 


1 


1 


0 


1 


1 


1 




MED 


3 


3 


0 


0 


3 


3 




LHA 


1 


1 


0 


1 


1 


1 




LPD 


1 


1 


0 


1 


1 


1 




VF 


0 


0 


0 


1 


0 


0 




CAS 


0 


0 


0 


1 


0 


0 




ENG 


0 


0 


0 


1 


0 


0 




SOF 


0 


0 


0 


1 


0 


0 




AAAV 


0 


0 


0 


1 


0 


0 




SD 


0 


0 


0 


1 


0 


0 


Player 3 


MV22 


2 


1 


2 


1 


2 


1 




INF 


4 


3 


2 


1 


5 


1 




AAAV 


3 


2 


1 


0 


3 


3 




SD 


1 


1 


1 


0 


2 


1 




ENG 


1 


0 


1 


0 


0 


0 




CAS 


0 


0 


1 


0 


0 


0 




SOF 


0 


0 


1 


0 


0 


0 




LPD 


0 


0 


1 


0 


0 


0 




VF 


0 


0 


1 


0 


0 


0 




MED 


0 


0 


1 


2 


0 


0 


Player 4 


AH- 1W 


4 


0 


0 


0 


4 


0 




CAS 


2 


2 


1 


0 


2 


2 




INF 


0 


0 


2 


2 


0 


0 




MV22 


0 


0 


1 


1 


0 


0 




MED 


0 


0 


2 


1 


0 


0 




LHA 


0 


0 


1 


0 


0 


0 




VF 


0 


0 


1 


1 


0 


0 




AAAV 


0 


0 


1 


1 


0 


0 


Player 5 


SOF 


1 


1 


0 


0 


1 


1 




CAS 


1 


0 


0 


0 


1 


0 




ENG 


1 


1 


0 


0 


1 


1 
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APPENDIX C. ARCHITECTURES 



The following pages contain pictures of the 
organization structure of the various architectures used in 
A2C2 experiment number 3 . [Ref 1] . 



AO 




Figure 18. Architecture AO pre trigger. 
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Figure 19. Architecture AO Post -Trigger . 



A1 




Figure 20. Architecture A1 . 
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A2 




Figure 21. Architecture A2 . 



AO’ 




^ITALICIZED PLATFORMS ARE STATIONARY 



Figure 22. Architecture AO prime. 
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AO’ (Post) 




Figure 23. Architecture AO prime Post-Trigger. 
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APPENDIX D. THE A2C2 SCENARIO 



The document on the following pages is the fictitious 
operational order that was used for A2C2 experiment number 
three . [Ref . 1] . 



IMMEDIATE 



FROM: USCINCMED NAPLES IT 

JTF 1000 

TO: CJCS WASHINGTON DC 

USCINCCENT MACD ILL AFB FL 
USCINCLANT NORFOLK VA 
USCINCEUR VAIHINGEN GE 
CINCFOR FT MCPHERSON GA 
USCINCPAC HONOLULU HI 
USCINCTRANS SCOTT AFB IL 
USCINCSTRAT OFFUTT AFB NE 
COMMARFORPAC HONOLULU HI 
CINCPACFLT HONOLULU HI 

INFO: WHITEHOUSE SITUATION ROOM WASHINGTON DC 

SECSTATE WASHINGTON DC 
SECDEF WASHINGTON DC 
CSA WASHINGTON DC 
CMC WASHINGTON DC 
CNO WASHINGTON DC 

DISTR: CINC/DCINC/CCJ1/CCJ2/CCJ3/CCJ4/CCJ5/CCJ6 

FOR OFFICIAL USE ONLY 
OPER/REDNOSE// 

MSGID/ORDER/USCINCCENT// 

AMPN/SPECIAL HANDLING INSTRUCTIONS 
REF/A/ORDER/CJCS/O 1 1742Z NOV 97// 

REF/B/ORDER/CJCS/04 1 142Z NOV 97// 

NARR/JT STRAT CAP PLN (FY 97), CJCS ALERT ORDER// 
ORDTYP/OPORD/USCINCCENT 12-97// 

MAP/10 15/TUNSIA// 

MAP/1020/ ALGERIA// 

NARR/SC ALE 1 : 1 00,000// 

TIMEZONE/Z// 
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HEADING/TASK ORGANIZATION// 



5UNIT 

/UNITDES /UNITLOC /CMNTS 

/USCINCLANT 
/USCINCEUR 
/CINCFOR 
/USCINCPAC 
/USCINCTRANS 

/USCINCSTRAT 
/COMMARFORPAC 
/CINCPACFLT 
/HQ USMEDCOM FWD 
/HQ USMEDAF (MINUS) 

12 E-3A (AWACS) 

/HQ USNAVMED (MINUS) 

/SUPPORTING FORCES 
/COMSUPNAVFOR 
/CTG60.1 (CVBG) 

/ARG 55.2 
/ 1 MEB 
/MPS// 

GENTEXT/SITUATION 

1. (FOUO) Country Orange has attacked the friendly nation of Country Green, an U.S. ally. Attacking 
forces have succeeded in seizing Country Green port of Eastport. Country Green government has 
requested U.S. assistance in taking back port of Eastport and driving Country Orange forces from Country 
Green. 



/NORFOLK VA 
/VAIHINGEN GE 
/FT MCPHERSON GA 



/HONOLULU HI 
/SCOTT AFB EL 

/OFFUTT AFBNE 
/HONOLULU HI 
/HONOLULU HI 



/2 TAC ARLFT SQ 
/6KC-10 
/2 RC-135 
/I MEB 

/(JTF 1000) 



A. (FOUO) ENEMY FORCES 

(1) (FOUO) See current SITREP and DIN. The port of Eastport is protected by 
obstructions, mines, obstacles, and the presence of hidden enemy among the port facility buildings. Two 
beaches approx. 5 miles south of the port may be suitable for amphibious assault. Northernmost beach 
(designated “North Beach”) has road leading to the port. Southernmost beach (designated “South Beach”) 
has a road leading to the airfield. Waterborne approaches to the beaches are possibly mined. 

Commanding terrain to north of Red Beach believed occupied by enemy Heavy Mortar Platoon with a 
platoon of Infantry for security. This terrain dominates both North Beach and the port. Seizure and 
retention of this dominant terrain should be considered essential for successful attack on Red Beach and 
port. 



(2) (FOUO) There are two Orange bases inland. Intel reports indicate that mobile 
missile forces occupy one of the bases, but it is not known which. Each base is connected by road to the 
port-Red Beach road and the road to each base has a bridge. Missile units from either bas will have to 
travel down the road and cross the bridge to bring U.S. forces to within effective range. Orange tactics 
and the current situation dictate that Orange send an advanced force to secure the bridge before sending 
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any Transporter Erector Launchers (TELs) across. To prevent this, a Special Operations Force (SOF) has 
been inserted at an observation post (OP) near the bridges. Their mission is to determine which base the 
missile force occupies and blow up the bridge leading to that base. There is a significant amount of 
neutral commercial traffic on the connecting roads, and while the SOF sensors can detect traffic on the far 
side of the bridges, they cannot discriminate between neutral commercial traffic and a hostile advance 
force. Air (TARPS) or space based (SAT) sensors will have to be used to establish positive hostile 
identification (PHID). 

(3) (FOUO) Believed to be at the port, but hidden from view, is company-sized 
armored counterattack force that could move toward North Beach in response to any amphibious assault. 
Similar counterattack force may exist at airfield, which is located about 5 miles inland from the South 
Beach. These counterattack forces could inflict serious damage if not interdicted before they reach either 
beach. Off-road terrain between beach, port, airfield, and commanding terrain is swampy and 
treacherous; and is unsuitable for travel. Thus, all ground travel, with the exception of the SOF who are 
equipped with advanced All-Terrain Vehicles (AT Vs), must be on the roads. It is believed that one or 
both of the roads, which connect the port and airfield to the beaches, will be mined. Locations of any 
minefields are currently unknown. Port, airfield, both roads, both beaches, and commanding terrain are 
located within range of artillery strong points, which must be suppressed. Northernmost strong-point can 
fire on North Beach and port. Southernmost strongpoint can fire on both South Beach and airfield. 
Artillery pieces at both strong points are housed in reinforced concrete bunkers, with ammunition stored 
in deep underground bunkers. It is unlikely that even concentrated air attacks will completely disable the 
artillery strong points. Enemy can be expected to wheel out artillery pieces (from 8 to 24 at a time), set 
up, sight in, and fire in under 2.5 minutes. If friendly forces can get effective NSFS on target in less than 
2.5 minutes, the enemy will probably wheel their artillery pieces back into bunkers and wait until another 
time. 



(4) (FOUO) Enemy Surface-to-Air Missile (SAM) sites and decoys have been erected 
around the port and airfield. The SAM sites must be identified and destroyed before air support or helo- 
bome forces can safely be used for the attack on the port. To minimize collateral damage, the sites must 
be hit with guided munitions. 



(5) (FOUO) Enemy also has several Frog Missile Launchers (SCUD-like) capable of 
carrying chemical munitions. Frogs are believed to be hidden in the vicinity of both artillery strongpoints. 
They can emerge from covered positions, prepare warheads, and fire missiles within 4 minutes. Past 
experience has shown that Frog crews are more stalwart than artillery crews. They will continue to 
prepare and launch their missiles even if they are being suppressed by NSFS or artillery. 



(6) (FOUO) Submarine threat to U.S. Naval forces is considerable. Enemy Alfa-Class 
submarines are known to be in the area. To protect the fleet, these submarines must be detected and 
destroyed. 



(7) (FOUO) Enemy possesses HIND Helicopters, and has demonstrated the capability 
to launch anti-ship missiles from its helicopters. The only significant capability the ARG or CVBG 
possesses against these helicopters is one Stinger Platoon. 

(8) (FOUO) The enemy has significant air strike capability, and can launch anti-ship 
missiles from most of its strike aircraft. 
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(9) (FOUO) The enemy’s Maritime Special Forces also possess numerous fast patrol 
boats (PBs), that can either fire very potent torpedoes, be loaded with explosives for suicide missions, or 
carry troops and supplies to reinforce Orange forces. These can be engaged and destroyed by the CG, 
DDGs, FFGs, fighters, and Cobras. But, they have been camouflaged to resemble a type of commercial 
coastal craft common in the area, and they are known to travel at the same speed as coastal traffic to avoid 
giving away their identity. These PBs must be identified by either SAT, TARPS, or very close inspection 
by friendly surface platforms before they can be engaged. There are two popular coastal trade routes 
between the mainland and a large island to the east. One route goes to the north of Green and passes 
close to a small inlet which could support offloading of troops and supplies to Orange forces occupying 
the port area. The other route passes south along the east coast and passes close to a beach south of the 
airfield, which could support offloading of troops and supplies to reinforce Orange forces around the 
airfield. Maritime traffic along these routes, and in the region overall, must be positively identified to 
ensure the destruction of all hostile boats while avoiding attacking neutral shipping. 

(10) (FOUO) There is also a Silkworm threat along the coastline. These Silkworm 
missiles were placed in residential neighborhoods by the enemy because they knew U.S. planners would 
be reluctant to target residential areas. Accordingly, if U.S. forces want to target a Silkworm launcher, 
they must first get positive confirmation of its presence, using reconnaissance assets (TARPS, SOF, 
Satellite). Any strike must use precision guided munitions (CAS). 

B. (FOUO) FRIENDLY FORCES. JTF will be comprised primarily of assets organic to 
Mediterranean Command (MEDCOM). A theater-level JFACC and other friendly forces are operating 
against the enemy in Country Green, but not in concert with the JTF. This forces the requirement to 
identify contacts prior to attacking to ensure friendly and neutral forces are not destroyed. 

(1) (FOUO) JTF will consist of one Aircraft Carrier Battle Group (CVBG), and a 
Amphibious Ready Group (ARG) with embarked Marines. The ARG will be composed of 1 LHA and 1 
LPD. CVBG will be composed of 1 CV, 1 AEGIS cruiser, 2 DDGs, and 2 FFGs. 



(2) (FOUO) The CVBG and ARG aircraft available to support the JTF are 4 sections of 

F-14s, 4 sections of F/A-18s, and 1 TARPS equipped F-14. The F/A-18s from the CV 

are equipped with Laser Guided Bombs (LGBs) and can attack Frog missile sites or confirmed Silkworm 
sites, or they can be used to provide Close Air Support (CAS) for friendly ground units. The F-L4s can be 
used for Anti-Air Warfare (AAW) and for Combat Air Patrol (CAP). The F-14 TARPS can be used for 
reconnaissance missions only. 

(3) (FOUO) In addition to TARPS, the JTF has access to an imagery satellite (SAT 
platform) which can provide continuous wide-angle “detection” coverage throughout the objective area. 
High-resolution “identification” coverage is available for a small (movable) area. 

(3) (FOUO) Two DDGs will be in position to provide NSFS. Small Minesweeping 
Craft (SMCs) are attached to the ARG to clear sea mines if detected. 

(4) (FOUO) The Marine amphibious forces are embarked on the ARG. The ARG is 
composed of three Advanced Amphibious Assault Vehicle (AAAV)-mounted rifle companies, three V-22 
Osprey-mounted helibome rifle companies, 4 sections of AH-1 W SeaCobras (indivisible), two 
mineclearing boats (SMCs), two engineer platoons, and three of MEDEVAC helicopters. Engineers must 
be used to breach any minefields encountered by JTF ground forces. Cobras are the only JTF assets which 
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by themselves are effective against armored formations. Two Stinger Detatchments will provide a close-in 
anti-air capability. 



(5) (FOUO) Ground forces have unmanned aerial vehicles (UAVs) flying in support 
for the duration of the operation. Continuous live feed will be fed to the Common Operational Picture 
(COP) available to all friendly forces. 

GENTEXT/MISSION 

2. (FOUO) On order, JTF 1 ground forces will seize and defend Country Green Port of Eastport, to allow r 
introduction of follow' on forces in support of Country Green government troops. Sea-based forces will 
support amphibious assault with CAS, naval gunfire, and air defense assets to defend the CVBG and ARG 
from air, surface, and subsurface threats.// 

GENTEXT/EXECUTION/ 

3 . (FOUO) CONCEPT OF OPERATIONS 

A. GROUND. The SOF will be inserted prior to the commencement of the amphibious 
landings. One AAAV-mounted rifle company will land on each beach near-simultaneously. As a 
prerequisite to this, one helibome rifle company will secure the commanding terrain overlooking Red 
Beach and the port in a coordinated attack. Once BOTH beaches and commanding terrain are secure, the 
two AAAV-mounted companies will proceed on foot down the roads from their respective beaches, 
clearing minefields with engineer platoons, killing counterattack forces with Cobras, and conducting 
MEDEVACS as necessary. The roads must be cleared prior to attacking the port or airfield. The SOF 
should conduct surveillance to locate the enemy missile force and destroy the applicable bridge, then 
proceed as directed to assist in assaults on the port and airfield. The UAVs will keep the artillery strong 
points and the suspected FROG sites under constant surveillance, so that NSFS or CAS assets can be 
brought to bear immediately if they are needed. Once the roads have been cleared, the AAAV-mounted 
companies will take the port and airfield. A helibome company will assist the company attacking the 
airfield. It is important that once the AAAV-mounted companies land on the beach, the airfield and port 
be taken as quickly as possible, before the enemy has a chance to organize his defense and send 
reinforcements. It is desired that final assaults on the airfield and port occur simultaneously, in order to 
present the enemy commander with the most confusing environment possible. How ever, if one attack 
must occur before the other, the airfield has the priority. If the airfield attack is held up for any reason, 
the port attack should wait to retain the synergism of concurrent attacks. If the port attack is held up, the 
airfield attack should go forward. 

B. MARITIME. Due to hydrographic limitations, the ARG and the CVBG will have to be 
significantly separated during the operation, enough to preclude them from being under a Joint Air 
Defense umbrella provided by the AEGIS Cruiser. Thus, the AEGIS Cruiser will remain with the CVBG, 
but will position itself so that it can rapidly move from the CVBG to the ARG if that becomes necessary. 
Additionally, the two DDGs are inshore, providing NSFS support, while the FFGs are primary ASW 
platforms for the CVBG. The FFGs performing ASW will, like the AEGIS Cruiser, position themselves 
so that they can quickly move to support the ARGs if that is necessary. The frigates, AEGIS cruiser, and 
destroyers can attack or be attacked by the enemy patrol boats. The ARGs will launch the Marines for the 
initial assault on Ted and Blue Beaches at the commencement of the operation, and will launch the 
minesweeping boats, SeaCobras, MEDEVAC helos, the air assault for the attack on the airfield, etc. when 
called to do so. The destroyers will provide NSFS to suppress enemy artillery ashore and for other 
missions when requested to do so. If a suspected Silkworm launcher is detected, TARPS, SOF, or 
Satellite must identify it before it can be destroyed. Silkworm and SAM sites require a coordinated laser 
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designation in order to achieve a perfect attack. A Silkworm launcher detected at the northernmost site 
threatens the CVBG, and one at the southermost site threatens the ARGs. SAM sites protect the port and 
airfield. 



4. (FOUO) FIRST TASK ASSIGNMENT CLF. On order of the JTF 1, land two AAAV-mounted 
companie on Red Beach and Blue Beach concurrently. Simultaneously seize commanding terrain to the 
north of Red Beach with one helibome company. Once the beach and commanding terrain are secure, 
attack along the roads from the beaches to the port and airfield with the AAAV-mounted companies, 
clearing minefields with the attached Engineer Platoon, killing counterattack forces with assigned Cobras 
and conducting MEDE VACS as necessary. Once the roads have been cleared, conduct a simultaneous 
coordinated attack on the port and airfield with your AAAV-mounted companies and your helibome 
companies. 

(FOUO) SECOND TASK ASSIGNMENT CVBG. Support the CLF and subordinates by launching 
requested assets and providing fighter support. 



7. (FOUO) THIRD TASK ASSIGNMENT ARG. On order of JTF 1, ARG will initially clear mines 
from the beaches with the Minesweeping Boats. ARG will launch 3 Companies of Marines for the initial 
assault on Red and Blue Beaches and the hill. The ARG will launch the Cobras, MEDEVAC helos, the 
helibome company for the attack on the airfield. ARG will also, with NSFS DDGs, suppress artillery 
positions. 

8. (FOUO) COORDINATING INSTRUCTIONS. 



A. (FOUO) This order effective for planning upon receipt and execution on order. 

B. (FOUO) Dirlauth for planning and operations with Info CJCS and CINCMED. 

C. (FOUO) ROE will be per CINCMED OPLAN 1234. 

D. (FOUO) Friendly forces will have a UAV (launched from the ARG) airborne for the duration 
of the operation. The UAV’s will keep the artillery strong-points and the suspected FROG sites under 
constant surveillance, so that NSFS or CAS assets can be brought to bear immediately if needed. 



E. (FOUO) If the airfield attack is held up for any reason, the port attack will be delayed to 
retain the synergism of concurrent attacks. If the port attack is held up, the airfield attack will go forward. 

F. (FOUO) The attack on the airfield has priority, because enemy buildup/sustainment of forces 
can be most quickly and effectively achieved through air transport. 



If 

GENTEXT/ADMIN AND LOG/ 

7. (FOUO) Per CINCMED OPLAN 1234, as amended herein.// 
GENTEXT/COMMAND AND SIGNAL/ 

8. (FOUO) USCINCMED is supported CINC. 
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9. (FOUO) CJTF 1 is on-the-scene Commander and will exercise OPCON of advance forces until HQ 
USCINCMED FWD is activated. 

10. (FOUO) Command relationships as outlined in Annex J, C1NCMED OPLAN 1234. 

11. (FOUO) Communications guidance as outlines in Annex K, CINCMED OPLAN 1234 as amended 
herein.// 

AKNLDG/Y // 

DECL/OADR// 
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APPENDIX E. CHANGES MADE TO THE PARAMETRIC DATABASE 

The following changes were made to the parametric 
database. The parametric database can be launched from a 
standard MDS login (see Appendix F) by right click the mouse 
and selecting APPLICATIONS -> PARA EDITOR. For more 
information on editing the parametric database, contact Mac 
Garrabrants, Project Manager, Modeling and Simulation, 
VisiCom Labs. [Ref. 3] . 

A. LAND MINES 

Only the lowest density of mines were used. 
Additionally, the removal settings were changed to 1 minute 
per man per square meter of mines, and a maximum work crew 
of 1000. These changes were made to facilitate mine removal 
by the engineers. At the default settings, removing a small 
minefield can take hours. By increasing the personnel in a 
standard engineering squadron, the removal time be lowered 
even more to meet the needs of the A2C2 scenario. 

B . BRIDGES 

Like land lines mines the removal time was set to 1 
minute per man per square meter. The min work crew was set 
to 20, and the max crew was set to 200. The numbers can be 
varied. The more units working on the bridge removal in a 
coordinated effort, the more rapidly the bridge can be 
removed . 
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C . DEFAULT TERRAIN 

The default terrain settings were set to allow all 
units to move at the fastest speed possible. These 
settings, in conjunction with the move and speed override 
commands will allow units to move in a predictable manner 
over any terrain. 

D. SHIP MAXIMUM DETECTION RANGE 

In order to detect sea mines, the maximum detection 
range on ship used in this experiment was set to 8000 
meters. This setting is only useful if the sea mines 
capability is implemented in the MTWS version of the 
scenario. A sea mine removal technique was not developed 
because of time constraints. 
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APPENDIX F. STARTING MTWS 



The following are startup procedures for MTWS. A 
system administrator who is knowledgeable about HP UNIX 
operating systems should be available for any operating 
system specific issues. 

A. BEFORE LOADING MTWS 

All of the computer workstation on the MTWS network 
that are to be used in an exercise should be powered on 
prior to loading MTWS. There are three types of computer 
terminal that are used in an MTWS network that must be 
present before an MTWS simulation can be loaded and run. 

1. MTWS System Control (MSC) 

This is the system that is the primary interface that 
is used to create, load, and control MTWS exercises. 

2 . MTWS Application Network (MAN) 

There can be multiple MAN stations on an MTWS network, 
but for an exercise the size of the A2C2 scenario, only one 
is necessary. The MAN stations control the actual 

simulation of the scenario. In the case of larger exercises 
using multiple MAN stations, each MAN will execute a 
particular set of computations apply to specific aspects of 
the scenario, such as Air operations, ship- to- shore 
operations, or ground movements. The MAN stations are 
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configured through the MSC, so human interaction is required 
with the MAN terminal except to power them on and off. 

3. MTWS Display Station (MDS) 

The MDS stations are the primary interface between the 
MTWS simulation and the participants of an exercise. Most 
exercises will use multiple MDS stations including A2C2 . 
The MDS station displays the map layout of the scenario, and 
provides the means for the MTWS operators to enter commands 
that direct units. 

B . STARTING MTWS 

1. Start MSC 

The user needs to know the correct user ID and password 
to log on to the MSC. These should be available from the 
local network system administrator. Once the MSC is logged 
on, the should click the right mouse button on an area of 
the screen that contains no windows or icons. A menu will 
appear, and the user should select APPLICATIONS -> START 
SYSOP -> MTWS. 

Three windows will appear including the MTWS Sys Ops 
window. In this window, select the SYSTEM CONTROL- > ADMIN - 
> START MSC menu option. Wait until the MTWS Sys Ops window 
indicates that the MSC has started. 

2. Load MAN 

In the MTWS Sys Ops window, select SYSTEM CONTROL -> 
APPLICATIONS -> LOAD MAN. A window entitled Man Hosts 
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appears, and displays all the possible MAN stations that 
could be used. For A2C2 only select MAN001. Press the OK 
button in the MTWS Sys Ops window. Wait until the MTWS Sys 
Ops window indicates that the MAN has loaded. In the 
meantime, the MAN station (s) should automatically logon, and 
a series of windows and icons will appear. 

C. LOADING OR CREATING AN EXERCISE 

At this point in the MTWS loading process, the user 
will have the option to either load an existing scenario, or 
create a new one . 

1. Creating an Exercise 

To create an exercise, select the EXERCISE CONTROL -> 
DATABASE -> EXERCISE -> CREATE menu option in the MTWS Sys 
Ops window. The exercise configuration window will appear. 
The user should enter the appropriate information. After an 
exercise has been created, follow the procedures in the next 
section to load the exercise. 

2 . Loading an Exercise 

In the MTWS Sys Ops window, select the EXERCISE CONTROL 
-> DATABASE -> EXERCISE -> LOAD menu option. The user 
should wait until the MTWS Sys Ops window displays the 
message saying the the exercise and terrain load are 
complete . 

Next, the system CONTROL -> APPLICATION -> START APP 
menu option should be chosen from the MTWS Sys Ops window. 
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MTWS will display a message when the application has 
successfully started. At this point, the user is ready to 
start playing or configuring the MTWS exercise. 
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